Kafka para comunicar microservicios por eventos

La comunicación entre microservicios define qué tan ágil y escalable puede ser tu arquitectura. Aquí aprenderás cómo conectar microservicios usando Kafka y un enfoque orientado a eventos, ideal si trabajas con sistemas distribuidos y necesitas que un servicio dispare a otro sin saturar la red.

¿Cómo se comunican los microservicios entre sí?

Dentro de un esquema de microservicios, cada servicio cumple una función específica y necesita conversar con otros para completar un flujo. Por ejemplo, un microservicio llamado add member funciona como endpoint que recibe información y la enruta a otros dos microservicios: uno para agregar un niño y otro para agregar un adulto, según el caso.

Esa coordinación no ocurre por arte de magia. Existen tres formas principales de hacerlo, y cada una tiene su lugar.

¿Cuáles son las 3 formas de comunicar microservicios?

Cada método responde a necesidades distintas de carga, velocidad y escalabilidad.

• HTTP: la forma más común en Internet, usada para conectar sitios web, APIs y servicios. Funciona, pero resulta compleja y pesada para microservicios por la cantidad de información que arrastra en cada llamada [0:48].
• gRPC: una forma de escalar las llamadas mediante procedimientos remotos. Más eficiente que HTTP en muchos escenarios [1:05].
• Orientada a eventos: la opción con mayor auge en la industria. Un microservicio publica un evento y otro lo escucha para arrancar [1:12].

¿Qué es la comunicación orientada a eventos? Es un patrón donde un microservicio genera un evento y otro servicio, que está escuchando, se activa al detectarlo. No hay llamada directa entre ellos, solo el evento como señal.

¿Por qué usar arquitectura orientada a eventos?

La lógica es elegante: add member crea un nuevo evento y un segundo servicio está escuchando ese evento. Cuando lo detecta, arranca su proceso. Así como el primer microservicio se activó por una llamada HTTP de un usuario, el segundo se activa por el evento que disparó el primero.

Esto permite encadenar microservicios al nivel que necesites. El récord visto hasta ahora es de 12 microservicios comunicados mediante un servicio de mensajería, aunque a esa escala el sistema empieza a sentirse burocrático.

La ventaja es clara: cada servicio se mantiene independiente, escucha lo que le interesa y reacciona sin acoplarse al emisor.

¿Qué es Kafka y por qué es el estándar de la industria?

Kafka es la herramienta que vincula la comunicación entre microservicios mediante eventos y, hoy por hoy, es prácticamente el estándar en la industria para este tipo de arquitecturas [1:42].

Fue creado en 2010 por LinkedIn y luego donado a la Apache Foundation, lo que lo convierte en open source. Esa es justo la razón por la que se usa tanto: sin importar el proveedor de nube que elijas, vas a encontrar una implementación de Kafka lista para invocar [2:14].

¿Qué hace Kafka en una arquitectura de microservicios? Funciona como un bus de eventos que permite establecer una lista de prioridades, recibir mensajes de un microservicio y entregarlos a los servicios suscritos que están escuchando.

¿Cuándo conviene usar Kafka frente a HTTP o gRPC?

Kafka brilla cuando necesitas desacoplar servicios, manejar grandes volúmenes de eventos y permitir que múltiples consumidores reaccionen a la misma información sin que el emisor sepa quiénes son. HTTP sigue siendo útil para llamadas síncronas directas, y gRPC para procedimientos optimizados entre servicios internos.

La decisión depende del flujo: si tu sistema vive de reacciones en cadena, eventos es el camino.

¿Cuál de las tres formas de comunicación usas hoy en tus proyectos? Cuéntame en los comentarios cómo resolviste el acoplamiento entre tus servicios.