Prácticamente todas las aplicaciones modernas requieren comunicarse con aplicaciones externas, ya sea para consultar o enviar datos a otra aplicación, pero que pasa cuando una aplicación necesita saber si hay alguna novedad en un sistema externo, como podemos saber si algo ha pasado de lo cual necesitamos enterarnos.
Problemática
Normalmente, cuando algo pasa en un sistema externo no tenemos forma de saberlo, si no hasta que vamos al sistema y lo consultamos, pero ¿cómo saber exactamente qué fue lo que cambio? no podemos simplemente ir y consultar toda la base de datos para comparar registro contra registro para identificar el cambio, lo cual se convierte en un problema.
O que pasa cuando un servidor se encuentra de tras de un firewalll que impide la comunicación bidireccional, por ejemplo, el navegador puede establecer conexión con el servidor, pero el servidor no puede iniciar una comunicación con el navegador, en ese caso, como logramos saber si hay algún cambio en el servidor, quizás la única solución sea actualiza la página para volver a realizar una nueva consulta al servidor.
O simplemente el servidor no cuenta con mecanismos para notificar de algún cambio a los interesados, lo que obliga al sistema interesado en realizar consultas repetitivas para traer los últimos cambios.
Solución
Una de las formas más rudimentarias, pero aun eficiente forma de obtener las actualizaciones de un sistema es mediante el Polling, el cual consiste en realizar una serie de consultar repetitivas y con una periodicidad programada en búsqueda de nueva información, de esta forma, el sistema interesado tendrá que ir al servidor y preguntar si hay nuevas actualizaciones, si las hay, el servidor las retornará, en otro caso, el cliente seguirá preguntando cada x tiempo hasta que encuentre nuevas actualizaciones. Un dato importante es que el Polling no se detiene nunca, es decir, encuentre o no actualizaciones, este seguirá preguntando por más actualizaciones.
En el patrón Polling se conoce como Requestor al componente que realiza las consultas recurrentes, mientras que el Provider corresponde al servidor que contiene los datos que pueden cambiar.
En este sentido, podemos ver en la imagen anterior, como el Requestor realizar una serie de consultas al Provider en búsqueda de nueva información, y no se detiene, incluso cuando encuentra nuevas actualizaciones, es por ello que, la única forma en que un Polling deja de realizar consultas es cuando lo apagamos manualmente, en otro caso, seguirá pregunta día y noche.
El Polling es un patrón que se debe de utilizar con cuidado, pues la consulta recurrente de nuevas actualizaciones trae un desgaste en el performance del Provider, ya que cada solicitud implica, por lo general, una consulta a la base de datos o al sistema de archivos, lo que hace que un abuso en la frecuencia de consulta sea un tema grave a considerar.
Por otro lado, es importante controlar el número de Requestor que estarán solicitando actualizaciones, pues no podemos permitir que cualquiera llegue y comience a tirarle consultas a Provider. Un ejemplo claro de esto es, una página web que requiere mostrar cierta información en tiempo real, la cual actualiza un reporte cada x tiempo, sin embargo, es una página web la cual muchos usuarios puede entrar al mismo tiempo, esto provocará que un número indeterminado de Requestor comience a realizar consultas al Provider, lo que puede llevar al proceso de consulta de actualizaciones a competir por los recursos de la misma operación.
Por ningún motivo debemos diseñar una arquitectura donde no podamos controlar el número de Requestor, si llegamos a un escenario como el de la imagen anterior, quiere decir que hemos hecho las cosas mal.
El patrón Polling se utiliza para consultar las actualizaciones de un sistema externo cuando es la única alternativa, es decir, cuando el Provider está fuera de nuestro control y no tenemos un mecanismo más eficiente para consultas las actualizaciones, como es el caso de los Webhook (los analizaremos más adelante).
Pueden existir diversos motivos por los cuales sea necesario utilizar un Polling, pero los más comunes son:
Consulta de nuevos archivos de texto, como facturas, pagos o catálogos diversos, como proveedores, clientes, cuentas, etc. Generalmente por medo de FTP
Consultas recurrentes sobre una base de datos en búsqueda de nuevos registros.
Consulta recurrente a un servicio de aplicación para saber el status de un determinado proceso.
Monitoreo del estado de salud de servicios e infraestructura.
Conclusiones
Polling es un patrón que hasta el día de hoy se sigue utilizando mucho, sin embargo, es un patrón que debemos utilizar cuando no tenemos una mejor forma de consultar las actualizaciones de un sistema externo, ya que su uso puede afectar el rendimiento del Provider. Por otro lado, tenemos que tener un control cuidadoso sobre todos los Requester que podrán realizar consultas, para evitar que cualquier pueda comenzar a realizar un número de consultas excesivas que afecten la operación del sistema.
Por otro lado, el Provider podrá contener (no obligatorio) controles que ayuden a determina el número de peticiones de los Requester con la intención de cortar el servicio en caso de un abuso en el número de consultas y la periodicidad de las mismas.
Finalmente, el patrón Polling es una excelente alternativa cuando debemos monitorear los cambios en sistemas de terceros, donde no tenemos control sobre ellos o que simplemente no fueron diseñados para notificar sus cambios de una mejor manera.
Acerca de este libro
Todo lo que acabas de ver en este artículo es solo una pequeña parte del libro Introducción a la arquitectura de software, el libro más completo en español sobre arquitectura de software, donde cubrimos los temas más importantes para convertirte en un arquitecto de software profesional.
¿Quieres convertirte en arquitecto de software pero no sabes cuál es el camino adecuando? o simplemente no sabes que guía estudiar para convertirte en arquitecto de software, te invito a que veas mi libro: