Los microservicios son servicios independientes que necesitan intercambiar datos para trabajar juntos. Cómo se comunican determina las características de escalabilidad, resiliencia y latencia del sistema.

TL;DR Los microservicios se comunican en dos estilos fundamentales: síncrono (un servicio llama a otro y espera una respuesta — REST, gRPC) y asíncrono (un servicio publica un mensaje y no espera — colas de mensajes, event streaming). El síncrono es más sencillo de implementar y razonar, pero crea acoplamiento y fallos en cascada. El asíncrono mejora la resiliencia y el desacoplamiento pero agrega complejidad. La mayoría de las arquitecturas de producción usan ambos: síncrono para solicitudes orientadas al usuario que necesitan respuestas inmediatas, asíncrono para procesamiento en segundo plano, notificaciones y eventos entre servicios.

Los dos estilos de comunicación

Comunicación síncrona

El Servicio A llama al Servicio B y espera la respuesta antes de continuar. El llamador queda bloqueado durante la solicitud.

Solicitud del Usuario → Servicio A → (bloqueado esperando) → Servicio B → respuesta → Servicio A → respuesta → Usuario

Características:

• Patrón simple de solicitud-respuesta
• El llamador sabe de inmediato si la solicitud tuvo éxito o falló
• Si el Servicio B está lento o caído, el Servicio A queda bloqueado (y potencialmente llega al timeout)
• Acoplamiento temporal estrecho — ambos servicios deben estar disponibles simultáneamente

Protocolos: REST sobre HTTP, gRPC, GraphQL, SOAP

Comunicación asíncrona

El Servicio A publica un mensaje y continúa inmediatamente sin esperar. El Servicio B procesa el mensaje a su propio ritmo.

Servicio A → publica mensaje → Message Broker → Servicio B procesa (después)

Características:

• El publicador y el consumidor están desacoplados en el tiempo — el consumidor puede estar desconectado
• Mayor resiliencia — si el Servicio B está caído, los mensajes se acumulan y se procesan cuando se recupera
• Sin confirmación inmediata del éxito del procesamiento
• Más difícil de rastrear el flujo de extremo a extremo

Protocolos: Colas de mensajes (RabbitMQ, SQS, ActiveMQ), event streaming (Kafka, Kinesis)

Protocolos síncronos

REST (HTTP)

REST es el protocolo síncrono más común. Los servicios exponen endpoints HTTP; los llamadores hacen solicitudes GET, POST, PUT, DELETE y reciben respuestas JSON.

Fortalezas: Legible por humanos, ampliamente soportado, fácil de depurar, independiente del lenguaje. Debilidades: Verboso (sobrecarga de JSON), sin contrato fuerte, HTTP/1.1 tiene limitaciones de una-solicitud-por-conexión.

Mejor para: APIs públicas, servicios orientados al usuario, operaciones CRUD, servicios consumidos por clientes web/mobile.

gRPC

gRPC usa Protocol Buffers (serialización binaria) y HTTP/2. Genera código de cliente y servidor fuertemente tipado a partir de una definición de esquema .proto.

service OrderService {
  rpc GetOrder (OrderRequest) returns (OrderResponse);
  rpc StreamOrders (OrderRequest) returns (stream OrderResponse);
}

Fortalezas: 5–10× más eficiente que REST/JSON, contrato fuerte (schema-first), streaming bidireccional, clientes autogenerados. Debilidades: No legible por humanos, más difícil de depurar sin herramientas, soporte deficiente en navegadores (requiere gRPC-Web).

Mejor para: Llamadas internas de servicio a servicio, servicios de alto throughput, servicios que necesitan streaming.

GraphQL

GraphQL permite que los clientes especifiquen exactamente qué datos necesitan en una sola solicitud. Un endpoint atiende todas las consultas.

Fortalezas: Elimina el over-fetching y under-fetching, consultas flexibles, esquema fuertemente tipado. Debilidades: Caché complejo, problema de consulta N+1, excesivo para CRUD simple.

Mejor para: Servicios agregadores, APIs consumidas por múltiples tipos de clientes con diferentes necesidades de datos.

Patrones asíncronos

Colas de mensajes

Una cola de mensajes almacena mensajes hasta que un consumidor los recupera y procesa. Cada mensaje normalmente es procesado por un consumidor (punto a punto).

Servicio de Pedidos → [mensaje Pedido Creado] → Cola → Servicio de Pagos (un consumidor)

Casos de uso: Procesamiento de pedidos, envío de correos, trabajos en segundo plano, descarga de operaciones lentas del camino de la solicitud.

Ejemplos: RabbitMQ, Amazon SQS, Azure Service Bus.

Event streaming

En el event streaming, los servicios publican eventos en un log (el stream). Múltiples consumidores pueden leer y reproducir eventos de forma independiente — cada uno en su propio offset.

Servicio de Pedidos → [evento Pedido Creado] → Tema Kafka → Servicio de Pagos
                                                            → Servicio de Inventario
                                                            → Servicio de Analytics

Los eventos persisten en el log durante un período de retención configurable (días a siempre), permitiendo la reproducción y que nuevos consumidores se pongan al día desde el principio.

Casos de uso: Analytics en tiempo real, event sourcing, registros de auditoría, fan-out a múltiples consumidores.

Ejemplos: Apache Kafka, Amazon Kinesis, Confluent Cloud.

Arquitectura orientada a eventos

En los sistemas orientados a eventos, los servicios reaccionan a eventos publicados por otros servicios. Los servicios están completamente desacoplados — no saben quién está escuchando.

Coreografía: Cada servicio escucha eventos y reacciona de forma independiente. Sin coordinador central.

Servicio de Pedidos publica → Pedido Creado
Servicio de Pagos escucha → cobra la tarjeta → publica Pago Confirmado
Servicio de Inventario escucha → reserva stock → publica Stock Reservado

Orquestación: Un orquestador central le dice a cada servicio qué hacer en secuencia.

Orquestador de Pedidos → llama al Servicio de Pagos → llama al Servicio de Inventario → llama al Servicio de Envíos

Elegir síncrono vs asíncrono

Descubrimiento de servicios

En los microservicios, las instancias de servicio son dinámicas — escalan hacia arriba y hacia abajo, y sus direcciones IP cambian. El descubrimiento de servicios permite que los servicios se encuentren entre sí sin direcciones codificadas de forma fija.

Descubrimiento en el lado del cliente: El servicio llamador consulta un registro de servicios (Consul, Eureka) para encontrar instancias disponibles, luego balancea la carga de las solicitudes por sí mismo.

Descubrimiento en el lado del servidor: Las solicitudes van a un balanceador de carga o API gateway, que consulta el registro y enruta apropiadamente.

Descubrimiento basado en DNS: Los servicios se registran con DNS; los llamadores resuelven el nombre del servicio a una IP. Simple pero limitado en sofisticación.

Patrón de API gateway

Un API gateway es un punto de entrada único que maneja todas las solicitudes externas y las enruta al microservicio apropiado. Centraliza:

• Autenticación y autorización
• Rate limiting
• Terminación SSL
• Enrutamiento de solicitudes y balanceo de carga
• Agregación de respuestas (combinando respuestas de múltiples servicios)

Sin un API gateway, los clientes deben conocer todos los servicios individuales y gestionar la autenticación, los reintentos y el enrutamiento por sí mismos.

Manejo de fallos

Los microservicios introducen problemas de sistemas distribuidos. Patrones clave para la resiliencia:

Preguntas frecuentes

¿Cómo se comunican los microservicios entre sí? Los microservicios se comunican usando protocolos síncronos (REST sobre HTTP o gRPC), donde un servicio llama a otro y espera una respuesta, o mensajería asíncrona (colas de mensajes o streams de eventos) donde un servicio publica un mensaje sin esperar. La mayoría de las arquitecturas usan ambos — síncrono para solicitudes orientadas al usuario, asíncrono para procesamiento en segundo plano.

¿Cuál es la diferencia entre REST y gRPC en microservicios? REST usa HTTP y JSON — legible por humanos, ampliamente soportado, fácil de depurar. gRPC usa HTTP/2 y Protocol Buffers (binario) — 5–10× más eficiente, fuertemente tipado con clientes autogenerados, soporta streaming. REST es preferido para APIs externas/públicas y servicios más simples. gRPC es preferido para llamadas internas de servicio a servicio de alto throughput.

¿Qué es la comunicación asíncrona en microservicios? La comunicación asíncrona significa que un servicio publica un mensaje (a una cola o stream de eventos) y continúa sin esperar que otro servicio lo procese. Esto desacopla los servicios en el tiempo — el consumidor puede estar desconectado, lento o procesar mensajes en lotes. Mejora la resiliencia pero hace más difícil rastrear errores y razonar sobre la consistencia.

¿Qué es una cola de mensajes en microservicios? Una cola de mensajes es un intermediario que almacena mensajes entre un productor (remitente) y un consumidor (receptor). El productor envía mensajes sin saber si el consumidor está listo. El consumidor procesa los mensajes cuando está disponible. Cada mensaje normalmente se entrega a un consumidor. Ejemplos: RabbitMQ, Amazon SQS.

¿Qué es el event streaming vs las colas de mensajes? Las colas de mensajes entregan cada mensaje a un consumidor (punto a punto) y lo eliminan después del procesamiento. El event streaming (Kafka, Kinesis) persiste eventos en un log, y múltiples consumidores independientes pueden leer y reproducir eventos a su propio ritmo. Usa colas de mensajes para el procesamiento de tareas; usa event streaming para analytics, registros de auditoría y fan-out a múltiples consumidores.

¿Qué es un service mesh en microservicios? Un service mesh (Istio, Linkerd) es una capa de infraestructura que maneja la comunicación de servicio a servicio de forma transparente — proporcionando balanceo de carga, circuit breaking, reintentos, observabilidad y cifrado mTLS entre servicios sin requerir cambios en el código de la aplicación. Intercepta el tráfico a través de proxies sidecar que se ejecutan junto a cada servicio.

¿Cuál es la diferencia entre coreografía y orquestación en microservicios? En la coreografía, cada servicio reacciona a los eventos y publica sus propios eventos — sin coordinador central. En la orquestación, un servicio orquestador central llama explícitamente a cada servicio en secuencia y gestiona el flujo de trabajo. La coreografía está más desacoplada pero es más difícil de rastrear. La orquestación es más fácil de entender y depurar pero crea un punto central de acoplamiento.

¿Cómo manejan los microservicios la autenticación? Típicamente mediante JWT (JSON Web Tokens) validados en el API gateway. El gateway autentica la solicitud entrante y luego propaga la identidad del usuario (como un JWT o header de solicitud) a los servicios descendentes. Los servicios confían en la autenticación del gateway y se enfocan en la autorización — verificando si el usuario autenticado tiene permiso para realizar la acción solicitada.