En el subcapítulo anterior vimos SQS, donde un mensaje va a un consumidor que lo procesa. Pero a veces quieres lo contrario: que un mismo mensaje llegue a muchos destinatarios a la vez. Para eso existe SNS (Simple Notification Service), el servicio de notificaciones de AWS. Es el complemento perfecto de las colas.

Imagina que en una tienda se realiza un pedido, y cuando eso ocurre quieres que varios sistemas se enteren al mismo tiempo:

• El servicio de facturación (para generar la factura).
• El servicio de inventario (para descontar el stock).
• El servicio de emails (para avisar al cliente).
• El servicio de analítica (para las estadísticas).

Con una cola SQS, el mensaje iría a un consumidor. Aquí queremos que el aviso «hay un nuevo pedido» llegue a todos a la vez. Eso es exactamente lo que hace SNS.

SNS funciona con el modelo publicador/suscriptor (pub/sub):

• Un publicador envía un mensaje a un topic (tema).
• Todos los suscriptores de ese topic reciben una copia del mensaje, a la vez.

• Topic (tema): el «canal» al que se envían los mensajes (ej. nuevo-pedido).
• Suscripción: cada destinatario se suscribe al topic para recibir sus mensajes.

Analogía: SNS es como una lista de difusión o un canal de radio. El locutor (publicador) emite un mensaje una vez, y todos los que están suscritos al canal lo reciben simultáneamente. El locutor no necesita saber cuántos oyentes hay ni quiénes son.

Es fundamental no confundirlos:

En resumen: SQS reparte trabajo (un mensaje, un trabajador); SNS difunde avisos (un mensaje, todos enterados).

Un topic SNS puede tener muchos tipos de suscriptores, lo que lo hace muy versátil:

• Una función Lambda (para que reaccione al evento, Capítulo 14).
• Una cola SQS (¡muy importante! lo vemos enseguida).
• Un email (SNS envía un correo).
• Un SMS (un mensaje de texto a un móvil).
• Un endpoint HTTP/HTTPS (avisar a otro sistema vía web).

Aquí está la combinación más poderosa, y una de las arquitecturas más usadas en AWS: el patrón fan-out («abanico»). Consiste en poner un topic SNS que difunde a varias colas SQS, una por cada servicio.

¿Por qué es tan bueno combinarlos? Porque suma lo mejor de los dos:

• SNS difunde el aviso a todos los servicios a la vez (uno a muchos).
• Cada cola SQS da a su servicio la resiliencia y el amortiguamiento que vimos en el subcapítulo 15.1: si el servicio de inventario se cae, sus mensajes esperan en su cola sin perderse, mientras los demás servicios siguen funcionando con normalidad.

Ejemplo del mundo real: en la tienda, se publica «nuevo pedido» en el topic SNS. Llega instantáneamente a las colas de facturación, inventario, emails y analítica. El servicio de analítica está en mantenimiento (caído), pero sus mensajes se acumulan en su cola y los procesará cuando vuelva. Mientras tanto, facturación, inventario y emails procesan los suyos sin problema. Ningún pedido se pierde y ningún servicio bloquea a los demás.

Este patrón fan-out es la base de muchas arquitecturas dirigidas por eventos (lo veremos en el subcapítulo 15.4 y en el Capítulo 28).

• SNS es el servicio de notificaciones con modelo publicador/suscriptor: un mensaje enviado a un topic llega a todos sus suscriptores a la vez (uno a muchos).
• Diferencia clave con SQS: SQS reparte trabajo (un mensaje → un consumidor); SNS difunde avisos (un mensaje → todos los suscriptores). Como una lista de difusión o un canal de radio.
• Los suscriptores pueden ser Lambdas, colas SQS, emails, SMS o endpoints HTTP.
• El patrón fan-out (SNS → varias colas SQS) combina lo mejor de ambos: difusión a todos los servicios + resiliencia y amortiguamiento de cada cola. Es una de las arquitecturas más usadas.

En el siguiente subcapítulo veremos un servicio de eventos más moderno y flexible que amplía estas ideas: EventBridge.