Cuándo usar SQS, SNS o EventBridge

AWS ofrece varias formas de mover mensajes entre componentes, pero SQS, SNS y EventBridge resuelven problemas distintos. Elegir el servicio equivocado puede introducir complejidad innecesaria o dejarte sin el comportamiento de buffering, enrutamiento o entrega que tu carga de trabajo realmente necesita.

La forma más simple de decidir es empezar por una pregunta: ¿qué debe pasar con el mensaje después de que se publica?

Qué hacen realmente SQS, SNS y EventBridge

Amazon SQS: encolar trabajo para su procesamiento

Amazon Simple Queue Service (SQS) es una cola de mensajes. Un productor coloca un mensaje en la cola, y un consumidor lo recupera y lo procesa.

Lo importante es que el mensaje espera en la cola hasta que un consumidor pueda atenderlo. Eso hace que SQS sea útil cuando productores y consumidores operan a velocidades distintas.

Un patrón típico es:

API → SQS → Worker Lambda

Si de pronto llegan 5,000 solicitudes, la API puede encolar el trabajo en lugar de requerir que tus workers o tu base de datos absorban las 5,000 operaciones de inmediato.

Las colas estándar de SQS ofrecen entrega al menos una vez (at-least-once), por lo que los consumidores deben ser idempotentes: procesar el mismo mensaje más de una vez no debería producir resultados incorrectos. Las colas FIFO agregan capacidades de orden y deduplicación cuando esos requisitos importan.

Usa SQS cuando necesites buffering, procesamiento asíncrono, reintentos o suavizado de carga de trabajo.

Amazon SNS: enviar un mensaje a muchos suscriptores

Amazon Simple Notification Service (SNS) usa un modelo de publicación/suscripción (pub/sub).

Un productor publica una vez:

Aplicación → SNS
                ├── Lambda
                ├── SQS
                └── Endpoint HTTP

Cada suscriptor recibe su propia copia del mensaje.

Eso hace que SNS sea útil para un fan-out simple. Por ejemplo, una notificación InvoiceGenerated podría necesitar disparar un proceso de email, un pipeline de analítica y una integración contable downstream.

Las suscripciones de SNS también pueden usar políticas de filtro para que los suscriptores reciban solo los mensajes que coincidan con atributos seleccionados o valores del cuerpo del mensaje.

SNS sigue siendo principalmente un mecanismo de entrega, no una cola de trabajo durable. Cuando un suscriptor debe poder procesar el trabajo de forma confiable más adelante, un patrón común es SNS → SQS, dando a cada consumidor su propia cola.

Usa SNS cuando el requisito principal sea difundir un mensaje a múltiples suscriptores conocidos.

Amazon EventBridge: enrutar eventos según reglas

Amazon EventBridge es un enrutador de eventos.

En lugar de pensar principalmente en enviar un mensaje a un destino, piensa en publicar algo que sucedió:

{
  "source": "orders",
  "detail-type": "OrderCreated",
  "detail": {
    "orderId": "1234",
    "region": "CA"
  }
}

EventBridge evalúa el evento contra un conjunto de reglas y lo reenvía a los targets correspondientes.

Una regla podría decir:

OrderCreated + region=CA → servicio de fulfillment en Canadá
OrderCreated + total>5000 → flujo de revisión de fraude
OrderCancelled → servicio de inventario

EventBridge puede recibir eventos de aplicaciones propias, servicios de AWS y orígenes SaaS compatibles, y luego enrutar los eventos que coincidan hacia servicios de AWS y otros destinos.

Usa EventBridge cuando las decisiones de enrutamiento dependan del contenido del evento, o cuando muchos productores y consumidores independientes necesiten bajo acoplamiento.

Un marco práctico de decisión

Empieza con estas preguntas:

1. ¿El trabajo necesita esperar de forma segura hasta que un consumidor pueda procesarlo? Usa SQS.

2. ¿El mismo mensaje debe llegar de inmediato a múltiples suscriptores? Usa SNS.

3. ¿Los eventos deben enrutarse de forma distinta según su contenido, origen o tipo? Usa EventBridge.

4. ¿Los suscriptores individuales también necesitan buffering y un comportamiento de reintento independiente? Combina servicios, por ejemplo:

SNS → SQS → Worker

o:

EventBridge → SQS → Worker

Estos servicios son complementarios. No es necesario forzar una arquitectura a usar solo uno de ellos.

Ejemplo: procesamiento de un pedido de e-commerce

Considera una aplicación que publica un evento OrderCreated.

EventBridge puede actuar como el enrutador central:

Servicio de Pedidos
     ↓
EventBridge
     ├── OrderCreated → SQS → Worker de Fulfillment
     ├── OrderCreated → Lambda de Analítica
     └── HighValueOrder → Revisión de Fraude

SQS protege al sistema de fulfillment de picos de tráfico, porque los pedidos pueden acumularse hasta que los workers tengan capacidad disponible.

Si varios sistemas necesitan exactamente la misma notificación sin un enrutamiento complejo, SNS podría en cambio distribuir ese mensaje hacia colas SQS separadas.

La arquitectura se vuelve más fácil de razonar cuando cada servicio tiene una única responsabilidad clara.

Trade-offs y errores comunes

Un error común es usar EventBridge simplemente porque el sistema se describe como “event-driven”. EventBridge agrega capacidades de enrutamiento potentes, pero un único productor alimentando a un único worker puede necesitar solo SQS.

Otro error es usar SNS solo para procesamiento asíncrono crítico. Si un consumidor downstream debe poder procesar mensajes de forma independiente después de una interrupción, colocar una cola SQS detrás de la suscripción SNS suele ofrecer un límite de procesamiento más sólido.

También evita asumir que la entrega de un mensaje implica un procesamiento de negocio exactamente una vez. SQS estándar puede entregar mensajes más de una vez, y los sistemas distribuidos pueden reintentar operaciones en varias capas. Los consumidores que actualizan pagos, inventario u otro estado deben diseñarse, por lo tanto, para ser idempotentes.

Elige según el trabajo

La distinción práctica es simple: SQS almacena trabajo en buffer, SNS difunde mensajes y EventBridge enruta eventos.

Empieza con el servicio más simple que satisfaga el requisito. Agrega combinaciones como SNS → SQS o EventBridge → SQS solo cuando el fan-out, el enrutamiento, el buffering o el manejo independiente de fallas lo requieran.