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

Question

Accepted Answer

Los servicios se comunican de forma **síncrona** (solicitud/respuesta sobre REST o gRPC) o **asíncrona** (mensajes/eventos a través de un broker como Kafka o RabbitMQ).

## Síncrona (solicitud/respuesta)

El llamador espera una respuesta. Simple e intuitivo, pero acopla la disponibilidad — si el servicio llamado está caído, el llamador se ve afectado.

```http
GET /orders/42 HTTP/1.1
Host: orders-service
Accept: application/json
```

## Asíncrona (mensajería/eventos)

El remitente publica un mensaje y continúa; los consumidores lo procesan más tarde. Esto desacopla los servicios en el tiempo.

```text
Order Service ──publish "OrderPlaced"──▶ [ Broker ] ──▶ Email Service
                                              │
                                              └──▶ Inventory Service
```

## Cuándo usar cuál

| Necesidad | Elija |
|---|---|
| Respuesta inmediata para el usuario | Síncrona |
| Desacoplamiento, almacenamiento en búfer, fan-out | Asíncrona |
| Fuerte acoplamiento temporal OK | Síncrona |
| Resiliencia ante interrupciones de servicios posteriores | Asíncrona |

## Trampa

Las largas **cadenas síncronas** (A → B → C → D) multiplican la latencia y la probabilidad de fallo. Prefiera asíncrona o agregación donde sea posible.

## Por qué es importante

El estilo de comunicación moldea la resiliencia del sistema: las llamadas síncronas son fáciles de razonar pero crean un acoplamiento fuerte en tiempo de ejecución, mientras que la mensajería asíncrona logra desacoplamiento al costo de la consistencia eventual.

La mayoría de los sistemas reales mezclan ambos — síncrona para lecturas orientadas al usuario, asíncrona para flujos de trabajo en segundo plano.

Necesidad	Elija
Respuesta inmediata para el usuario	Síncrona
Desacoplamiento, almacenamiento en búfer, fan-out	Asíncrona
Fuerte acoplamiento temporal OK	Síncrona
Resiliencia ante interrupciones de servicios posteriores	Asíncrona