gRPC vs. una cola de mensajes para la comunicación entre servicios — ¿cuándo elijo RPC síncrono vs. mensajería asíncrona?

#Dos preguntas distintas, no dos sabores de la misma herramienta

"¿Esta llamada debería ser gRPC o debería pasar por una cola?" en realidad está preguntando: ¿el que llama necesita conocer el resultado antes de poder continuar, dentro de la vida de su propia petición? Si la respuesta es sí, quieres RPC síncrono. Si quien llama puede seguir adelante y algo más simplemente debería eventualmente ocurrir como consecuencia, quieres mensajería asíncrona. Todo lo demás —latencia, acoplamiento, aislamiento de fallas, throughput— se deriva de esa única decisión.

#gRPC: RPC rápido, tipado y síncrono por defecto

gRPC es un framework de llamada a procedimiento remoto construido sobre HTTP/2, que usa Protocol Buffers para definir un contrato fuertemente tipado y versionado (un archivo .proto) a partir del cual se generan stubs de cliente y servidor en los lenguajes que uses. Soporta cuatro formas de llamada: unaria (una petición, una respuesta —el caso común—), streaming del servidor, streaming del cliente, y streaming bidireccional completo, y tiene propagación de deadlines y cancelación incorporadas en el protocolo, de modo que quien llama puede decirle a toda una cadena de llamadas downstream "tienes 200ms, no más." Quien llama bloquea (o, en código cliente asíncrono, espera) hasta obtener una respuesta o alcanzar ese deadline: ambos servicios quedan acoplados en el tiempo; si el destinatario está caído o lento, quien llama lo siente de inmediato.

#Colas de mensajes: desacopladas, con buffer, procesadas eventualmente

Una cola de mensajes o broker de eventos —Kafka, RabbitMQ, SQS/SNS— permite que un productor publique un mensaje y continúe de inmediato, sin ninguna expectativa de que el consumidor lo procese enseguida, ni siquiera de que el consumidor esté corriendo en ese momento. Esto te da tres cosas a la vez: disponibilidad desacoplada (el éxito del productor no depende de que el consumidor esté arriba), buffer natural de carga (un pico de tráfico se acumula como profundidad de cola en vez de como peticiones fallidas o conexiones agotadas), y fan-out (muchos consumidores independientes pueden suscribirse al mismo evento sin que el productor sepa ni le importe quiénes son). El costo es que la mayoría de los brokers garantizan solo entrega al menos una vez, así que cada consumidor debe ser idempotente, y el productor generalmente no tiene forma de saber si o cuándo se procesó realmente el mensaje.

#Comparando ambas cara a cara

#Los modos de falla te empujan hacia herramientas distintas

Una falla en un RPC síncrono es, por construcción, un riesgo de falla en cascada: si el servicio D está lento, y C lo llama con gRPC sin timeout, los propios recursos de C se acumulan esperando a D, y eso puede propagarse hasta el borde del sistema (exactamente el modo de falla cubierto en la lección de fallas en cascada de este módulo). La mensajería asíncrona esquiva ese riesgo específico porque el productor nunca bloquea esperando al consumidor, pero lo cambia por otro modo de falla: un consumidor atascado o caído produce un retraso silencioso y creciente en vez de un error visible inmediato, razón por la cual el lag del consumidor y la profundidad de la dead-letter queue deben ser métricas de primera clase con alertas, no algo que descubres durante un incidente.

#El outbox transaccional: hacer confiable la publicación asíncrona

Aparece un bug sutil en el momento en que intentas combinar "escribir en mi propia base de datos" con "publicar un evento al respecto": si escribes en la base de datos y luego publicas al broker como dos operaciones separadas, una caída entre ambas puede perder el evento, o, si publicas primero, puede salir un evento para una escritura que nunca se confirmó. El patrón de outbox transaccional resuelve esto escribiendo el evento, como una fila, en una tabla outbox dentro de la misma transacción de base de datos que la escritura de negocio, y haciendo que un proceso relay separado (o el propio stream de captura de cambios de la base de datos) lea esa tabla outbox y publique al broker, reintentando hasta lograrlo. Eso garantiza que el evento se publique si y solo si la transacción se confirmó: esto es lo mínimo indispensable para microservicios orientados a eventos confiables, y los entrevistadores lo escuchan específicamente.

#Guía práctica: la mayoría de los sistemas reales usan ambos

Trata esto como una decisión real por cada llamada, no como una elección a nivel de plataforma completa: una arquitectura de microservicios saludable típicamente usa gRPC (o REST?) para lecturas síncronas y cualquier llamada donde quien llama genuinamente no puede continuar sin una respuesta, y un bus de eventos para propagar cambios de estado a cada servicio al que le importen. Ver ambas tecnologías dentro del mismo sistema no es indecisión, es la forma normal de una arquitectura madura.

🧠 Check your understanding
0/2 · 0/2 answered
1. Un servicio de checkout necesita saber si un pago fue exitoso antes de poder mostrarle al cliente una página de confirmación. ¿Qué estilo de comunicación encaja mejor?
Mensajería asíncrona, porque los pagos nunca deberían bloquear una peticiónUna cola de mensajes sin respuesta, ya que la consistencia eventual siempre es preferibleRPC síncrono (por ejemplo, gRPC), porque quien llama no puede continuar sin el resultado dentro de la vida de la peticiónNo importa, ambas son funcionalmente idénticas para este caso
2. ¿Qué problema resuelve el patrón de outbox transaccional?
Reemplaza por completo la necesidad de un broker de mensajesHace que las llamadas gRPC sean más rápidas al agruparlas en lotesGarantiza que un evento se publique si y solo si la transacción de base de datos que lo originó realmente se confirmóElimina la necesidad de que los consumidores sean idempotentes