Considerando lo que nos depara para este 2021, en esta entrada acerco tres arquitecturas orientadas a eventos que no pueden faltar en tu portafolios, para solucionar la alta demanda de sistemas en tiempo real.
Es probable que te parezcan poco relevantes e incluso que ya las hayas consumido incluso aunque no lo sepas, pero no quita el hecho que conocer estas arquitecturas es fundamental para desarrollar soluciones en tiempo real.
Sistemas en tiempo real
No debería sorprenderte que no exista una definición exacta para explicar qué es una arquitectura en tiempo real, esto es algo que se repite siempre que se habla en el área de la arquitectura de software.
En esta área es mejor no pensar demasiado los conceptos, pues mientras más específico menos aplicaciones tiene. Muchas cosas suelen mantenerse altamente abstractas y eso está bien.
Para entender lo que es un sistema en tiempo real deberíamos definir qué es “tiempo real”, y resulta que la inmediatez (el tiempo de respuesta) de un sistema depende enteramente del caso de uso y de los requerimientos de éste. Puede ser de entre un milisegundo a varios minutos.
Sin complicarnos mucho, es un sistema que debe ofrecer una respuesta en un tiempo establecido, no cumplir con ello conlleva grandes consecuencias.
Entraremos más en detalle al respecto en una próxima entrada.
Arquitecturas en tiempo real
Existen una enorme cantidad de arquitecturas en tiempo real que podrás ver en una próxima entrada, además, cada una tiene aplicaciones más especificas pues las decisiones arquitectónicas impactan directamente sobre los atributos de calidad de nuestro sistema.
Es importante entender que muchas veces estos atributos de calidad entran en conflicto unos con otros, es nuestra responsabilidad buscar un equilibrio entre entre estos, buscando una solución lo suficientemente óptima para resolver el problema.
1. PubSub
Si bien este corresponde a la categoría de patrones de diseño arquitectónicos, es clave para entender la filosofía de los patrones arquitectónicos, pues los conceptos de ellos son tomados de Pub/Sub.
PubSub (de Publish/Suscriber) permite a una aplicación notificar de eventos a los consumidores, sin acoplar el remitente al receptor.
Este patrón está compuesto por tres partes:
- El publisher: Es quien tiene algo que notificar, quien emite el evento.
- El broker: Es quien recibe la notificación para reemitirla Es la aplicación en sí.
- El suscriptor: Es el interesado por el evento, el consumidor.
A su vez, los mensajes o eventos viajan por un canal especifico.
Este patrón permite desacoplar los sistemas que necesitan comunicarse.
Cada suscriptor puede ser administrado de forma independiente, y pueden crearse tantos como sea necesario, aumentando enormemente la escalabilidad y la separación de responsabilidades.
Luego, es la infraestructura del broker el responsable de garantizar que los mensajes se entreguen a los suscriptores interesados.
Generalmente, es aquí en el broker donde aplicas gran parte de las arquitecturas. Cada publisher y cada subscriber puede tener su propia infraestructura.
Podés leer más al respecto en una futura entrada.
2. Webhook
Webhook es probablemente la forma más popular de reaccionar a eventos en los últimos años.
Provee una implementación sencilla para el consumidor, pues generalmente utiliza HTTP como protocolo de comunicación.
Además, tanto para el consumidor como para el servidor ésta es una forma más sana de informar a los consumidores que ha ocurrido un evento, ninguna de las partes necesita recurrir al polling.
Webhook es en sí una implementación de PubSub, que actúa en el lugar del broker. En este caso, el publisher toma el nombre de Provider, y el subscriber el de Requester.
Para el requester, el provider puede ser anónimo o no, pero no ocurrirá en sentido contrario; el provider desconoce totalmente al requester.
Es muy importante aclarar que en esta arquitectura, el webhook es responsable de garantizar que los requesters reciban el evento.
Puede ser mediante reintentos o canales alternativos.
Las políticas para garantizar la notificación es propuesta por el provider y aceptada por el requester, y estas son totalmente independientes de la arquitectura.
El funcionamiento es claro.
- El Requester se registra en el sistema para ser notificado de un evento en particular, además, le ofrece una dirección en la cual el sistema deberá dejar la notificación.
- En un momento dado, el Provider emite un evento, delegandole al webhook la tarea de notificar a los requesters.
- El webhook, reemite el evento a la dirección indicada hasta asegurarse que el requester la haya recibido.
Podés leer más al respecto en una futura entrada.
3. Petición y respuesta asíncrona
Este patrón permite al servidor realizar una tarea asíncrona cuando el cliente requiere una respuesta clara. Es especialmente útil cuando webhook no es una posibilidad (pues el consumidor no es un servidor).
Es normal que las aplicaciones requieran un procesamiento complejo y lento para responder las peticiones de un cliente.
Muchos navegadores abortan la petición cuando el servidor se demora, además, cualquier otro conflicto puede ocurrir durante el tiempo de espera.
La filosofía de esta metodología es sencilla.
- El cliente realiza una petición compleja.
- El servidor responde rápidamente, enviándole una referencia a la ubicación final del recurso solicitado.
- Entonces, el cliente comienza realizar “polling” a la ubicación indicada.
- El servidor responderá a las repetitivas peticiones si el recurso está o no disponible.
- Una vez terminado el proceso de la petición original, el recuso estará disponible en la ubicación indicada, el cliente la obtendrá y hará lo que sea con esa información.
Podés leer más al respecto en una futura entrada.
Como cierre, es importante recordad que las arquitecturas suelen ser independientes de los protocolos de comunicación, por eso, próximamente hablaremos de Tres protocolos de comunicación en tiempo real para aplicar estas y muchas otras arquitecturas y metodologías que veremos a lo largo del año.
