SNS vs SQS vs Kinesis: Deja de Adivinar, Empieza a Elegir

SNS vs SQS vs Kinesis: Deja de Adivinar, Empieza a Elegir

Vamos a ser honestos: la primera vez que tuve que elegir entre SNS y SQS, me quedé mirando la consola de AWS durante 40 minutos, abrí siete pestañas y aún así dudé de mí mismo. Eso fue hace años, y hoy en día AWS tiene seis —sí, SEIS— servicios diferentes para entrega de eventos. Es abrumador incluso para arquitectos senior.

La cuestión es que esto no es realmente un problema difícil una vez que dejas de pensar en los servicios y empiezas a pensar en la **forma** de los datos. ¿Necesitas push o pull? ¿Reproducción? ¿Fan-out? ¿Enrutamiento basado en contenido? Esa es la verdadera decisión.

Déjame explicarlo con el marco que desearía haber tenido entonces.

Los Candidatos (Una Guía Rápida y con Opinión)

SNS — El Altavoz
SNS (Simple Notification Service, https://aws.amazon.com/sns/) es un servicio de push pub/sub. Publicas un mensaje, y SNS lo envía de inmediato a todos los suscriptores: funciones Lambda, colas SQS, endpoints HTTP, email, incluso push a móviles. Está diseñado para ser "dispara y olvida": SNS no retiene mensajes y casi no reintenta. Si nadie está escuchando, el mensaje se pierde.

**Úsalo cuando:** un evento debe desencadenar muchas acciones simultáneamente.

SQS — La Cola Fiable
SQS (https://aws.amazon.com/sqs/) es una cola basada en pull. Los productores dejan mensajes, y los consumidores los procesan a su propio ritmo. No es pub/sub; es punto a punto. Los mensajes viven hasta 14 días, y las colas FIFO te dan orden estricto y procesamiento exactamente una vez (exactly-once).

**Úsalo cuando:** estás desacoplando un productor de un consumidor y necesitas fiabilidad sin enrutamiento complejo.

Kinesis — La Cinta de la Máquina del Tiempo
Kinesis (https://aws.amazon.com/kinesis/) es una plataforma de datos en streaming. A diferencia de SQS, donde un mensaje se consume y elimina, Kinesis permite que múltiples consumidores lean el mismo stream de forma independiente y replay de datos hasta por 365 días. Obtienes un orden sólido por shard y un throughput masivo.

**Úsalo cuando:** tienes datos en streaming de alto volumen y necesitas capacidad de reproducción (replay).

MSK — Kafka Sin el Doler de Cabeza (O Menos, al Menos)
MSK (Managed Streaming for Apache Kafka, https://aws.amazon.com/msk/) es Kafka administrado. Obtienes el ecosistema completo de Kafka —topics, particiones, grupos de consumidores, Kafka Connect, ksqlDB— sin tener que construir el tú mismo cluster. Pero sigues siendo responsable de dimensionar brokers, ajustar y parchear el sistema operativo.

**Úsalo cuando:** ya tienes habilidades en Kafka, necesitas Kafka Connect o estás migrando un despliegue existente de Kafka.

EventBridge — El Enrutador Inteligente
EventBridge (https://aws.amazon.com/eventbridge/) es el nuevo que creció rápido. Es un bus de eventos con filtrado y enrutamiento potentes basados en contenido. No solo publicas y rezas: puedes filtrar, transformar y dirigir eventos a diferentes destinos según su contenido. También maneja eventos programados (un cron integrado) y se integra nativamente con más de 140 servicios de AWS.

**Úsalo cuando:** la lógica de enrutamiento depende del contenido del evento, o estás construyendo una arquitectura basada en eventos seria.

RabbitMQ — El Veterano Probado en Batalla
RabbitMQ (https://www.rabbitmq.com/) es el broker de código abierto que ya tiene una década. Soporta múltiples protocolos (AMQP, MQTT, STOMP), ofrece enrutamiento flexible con exchanges y bindings, y corre en cualquier lugar. En AWS, típicamente lo ejecutarías en EC2 (https://aws.amazon.com/ec2/) o usarías un servicio administrado de terceros.

**Úsalo cuando:** necesitas patrones de enrutamiento complejos como exchanges de topic con comodines, o soporte multi-protocolo.

La Matriz de Decisión (Tu Hoja de Truco)

Deja de comparar tablas de características. En su lugar, hazte estas seis preguntas:

| Pregunta | Mejor Opción |
|---|---|
| ¿Desacoplamiento uno a uno? | SQS |
| ¿Fan-out uno a muchos? | SNS o EventBridge |
| ¿Múltiples consumidores independientes? | Kinesis |
| ¿Ya sabes Kafka o necesitas el ecosistema Kafka? | MSK |
| ¿Enrutamiento basado en el contenido del mensaje? | EventBridge |
| ¿Enrutamiento complejo/existente + muchos protocolos? | RabbitMQ |

Mi filosofía: **por defecto, elige servicios nativos de AWS a menos que tengas una razón para no hacerlo.** Montar tu propio broker es una carga operativa innecesaria en 2026.

Escenarios del Mundo Real

Escenario 1: Pipeline de Pedidos de E-Commerce

Tienes una tienda online. Cuando se realiza un pedido, debes enviar un correo de confirmación, actualizar el inventario, activar el envío y notificar a detección de fraude.

Clásico fan-out. Mi elección: **SNS o EventBridge**. Publicas un evento "order.placed", y SNS lo envía a una Lambda de email, una cola SQS de inventario y un servicio de envío simultáneamente. Pero si quieres filtrado (como notificar *solo* a fraude para pedidos superiores a $100), las reglas basadas en contenido de EventBridge ganan. Obtienes consumidores más simples: solo reciben lo que les corresponde.

Escenario 2: Análisis de Clickstream

Tu plataforma recibe millones de clics por hora, y tres equipos —analítica, ML y seguridad— necesitan consumir esos datos de forma independiente. Cada equipo quiere un replay de al menos una semana.

Este es el territorio de **Kinesis**. Con SQS, que un consumidor lea un mensaje significa que se fue para todos los demás. Kinesis Data Streams permite que tres consumidores independientes lean el mismo stream de datos simultáneamente, cada uno a su propio ritmo. Si tu equipo de analítica ya habla Kafka, MSK es una alternativa justa, pero Kinesis requiere menos cuidado operativo.

Escenario 3: Sistema Legacy con Enrutamiento Complejo

Estás modernizando un viejo sistema de punto de venta que usa RabbitMQ con exchanges de topic como `order.created.retail` y `warehouse.stock.low`. Hay cientos de claves de enrutamiento conectadas a servicios backend.

Portar esa lógica a SNS sería brutal: SNS solo soporta filtrado de suscripción básico, no patrones complejos. **RabbitMQ** o **EventBridge** funcionan ambos. EventBridge te da integración nativa con AWS y un registro de esquemas, pero reconnectar todas esas reglas de enrutamiento lleva tiempo. Mantener RabbitMQ significa menos esfuerzo de migración pero te deja gestionando instancias EC2 por un tiempo considerable. Elegiría EventBridge solo si el equipo tiene el ancho de banda; de lo contrario, ejecuta RabbitMQ y concéntrate en problemas más grandes.

Consejos Prácticos de las Trincheras

1. **Empieza con SQS + Lambda.** Es el patrón asincrónico más simple en AWS. Maneja el 90% de las necesidades de desacoplamiento backend. Añade SNS cuando necesites fan-out, EventBridge cuando necesites lógica de enrutamiento inteligente.

2. **Piensa en el replay desde el día uno.** La pregunta difícil no es "¿mi servicio puede manejar un mensaje fallido?", sino "¿mi servicio puede *re-leer el mismo mensaje dos veces*?". Kinesis y MSK hacen que los replays sean naturales. SQS FIFO te da semántica exactly-once pero limita el throughput.

3. **Respeta los límites de retención.** SNS no retiene nada. SQS tiene un tope de 14 días. Kinesis alcanza los 365 días con retención extendida. MSK por defecto es 7 días (configurable a más). Si necesitas pistas de auditoría o reprocesamiento, elige en consecuencia.

4. **Usa long polling en SQS.** Acumula 20 segundos de mensajes en lugar de hacer polling constantemente de colas vacías. Este solo cambio puede reducir tu factura de SQS en un 90%.

5. **Evita el fregado completo.** He visto una Lambda activar un topic SNS, que publica a una cola SQS, que envía a otra Lambda, que vierte a Kinesis —para algo tan simple como una carga de archivos. Cada salto añade latencia y un nuevo modo de fallo. Solo porque *puedes* encadenar todo no significa que *debas*.

Preguntas Frecuentes

¿Se pueden usar SNS y SQS juntos?
Absolutamente —y es uno de los patrones más potentes en AWS. SNS distribuye a múltiples colas SQS, y cada cola se procesa independientemente por diferentes servicios. Combina el poder de fan-out de SNS con la fiabilidad, retención y reintentos de SQS. Este es el patrón detrás de la mayoría de las arquitecturas basadas en eventos serias en AWS.

¿Está EventBridge reemplazando a SNS?
No del todo, pero se acerca. EventBridge hace todo lo que SNS hace —pub/sub, fan-out— más filtrado basado en contenido, descubrimiento de esquemas e integración profunda con AWS. Para proyectos nuevos, yo elijo EventBridge por defecto. Pero si tienes un caso de uso simple de push a Lambda, SNS sigue siendo más simple de entender y operar.

¿Cuándo debería elegir MSK sobre Kinesis?
Elige MSK cuando tu equipo ya conoce Kafka, cuando necesitas Kafka Connect o ksqlDB, o cuando estás migrando una infraestructura existente de Kafka. Kinesis gana cuando estás empezando de cero, quieres menos carga operativa y no necesitas el ecosistema de Kafka.

¿Está RabbitMQ muerto en el mundo de AWS?
No, pero es de nicho. Brillan para lógica de enrutamiento compleja y soporte multi-protocolo. Muchas empresas todavía ejecutan RabbitMQ en producción. Pero si estás construyendo desde cero en AWS, preferiría fuertemente EventBridge o Kinesis. Gestiona la migración una vez y agradécete después.

Reflexiones Finales

El "mejor" servicio de mensajería no es el que tiene más características. Es el que se ajusta a la forma de tu problema: SQS para desacoplamiento simple. SNS para fan-out. Kinesis para streaming con replay. MSK para Kafka a escala. EventBridge para enrutamiento inteligente. RabbitMQ para complejidad de la vieja escuela.

Ahora tienes una matriz de decisión mental que me habría ahorrado 40 minutos y siete pestañas aquel primer día. Ve y construye algo.