Cerramos el capítulo de mensajería juntando las piezas (SQS, SNS, EventBridge) en los grandes patrones de arquitectura que habilitan. Más que servicios concretos, aquí hablamos de formas de diseñar sistemas que son robustos, flexibles y escalables. Entender estos patrones te convierte en arquitecto, no solo en usuario de servicios.

Ya lo vimos con SNS (subcapítulo 15.2): un publicador emite un mensaje y muchos suscriptores lo reciben, sin que el publicador sepa quiénes son.

La idea de fondo: quien emite el evento no conoce ni le importa quién lo va a recibir. Esto permite añadir nuevos suscriptores sin tocar al publicador.

Ejemplo: hoy, cuando hay un nuevo pedido, avisas a facturación e inventario. Mañana, marketing quiere enterarse también para enviar ofertas. Con pub/sub, solo añades un suscriptor al topic; el servicio de pedidos no se toca. El sistema crece sin romper lo existente.

Se implementa con SNS (difusión simple) o EventBridge (enrutado inteligente).

Es quizá el patrón más importante de todo el capítulo. Desacoplar significa que los componentes de un sistema no dependen directamente unos de otros: se comunican a través de un intermediario (una cola o un bus), no «llamándose» entre ellos.

Las ventajas del desacoplamiento (que ya vimos con SQS, subcapítulo 15.1):

• Resiliencia: si un componente falla, los demás siguen funcionando; los mensajes esperan.
• Escalado independiente: puedes escalar cada componente por separado según su carga.
• Mantenibilidad: puedes cambiar, actualizar o reemplazar un componente sin afectar a los demás (mientras respete el formato de los mensajes).
• Amortiguación de picos: la cola absorbe las avalanchas de tráfico.

Analogía: un sistema acoplado es como una conversación telefónica: ambos tienen que estar disponibles al mismo tiempo; si uno no contesta, no hay comunicación. Un sistema desacoplado es como enviar un mensaje de WhatsApp: lo envías y sigues con tu vida; la otra persona lo lee cuando puede. Mucho más flexible y resistente.

El desacoplamiento se logra con colas (SQS), notificaciones (SNS) y buses de eventos (EventBridge): todas las piezas de este capítulo.

Este es más avanzado, pero conviene conocerlo. Surge de un problema real: ¿cómo coordinas una operación que afecta a varios servicios, cuando alguno puede fallar a mitad?

Imagina una compra que implica tres pasos en tres servicios distintos:

¿Qué pasa si el paso 1 (cobro) tiene éxito, pero el paso 2 (inventario) falla porque no hay stock? Has cobrado al cliente por un producto que no puedes enviar. En un solo sistema usarías una «transacción» que lo deshace todo de golpe, pero aquí son servicios separados: no hay una transacción única que los abarque.

Una saga descompone la operación en una secuencia de pasos, donde cada paso tiene definida una acción compensatoria (cómo deshacerlo). Si un paso falla, se ejecutan las compensaciones de los pasos anteriores en orden inverso, dejando el sistema coherente.

Analogía: una saga es como una reserva de viaje con vuelo, hotel y coche. Si reservas el vuelo y el hotel, pero no hay coches disponibles, no te quedas con un vuelo y un hotel inútiles: el sistema cancela (compensa) el vuelo y el hotel para dejarte como al principio. Cada reserva sabe cómo cancelarse.

En AWS, las sagas se orquestan a menudo con Step Functions (lo veremos en el Capítulo 28), que coordina los pasos y las compensaciones, apoyándose en colas y eventos para comunicar los servicios.

Todos estos patrones comparten una misma filosofía, la de las arquitecturas dirigidas por eventos (event-driven): en vez de un gran sistema monolítico donde todo está entrelazado, construyes componentes pequeños e independientes que se comunican mediante mensajes y eventos. El resultado: sistemas más resilientes (un fallo no derrumba el todo), más escalables (cada pieza escala por su cuenta) y más fáciles de evolucionar (añades piezas sin romper las demás).

• Pub/Sub: el emisor publica y muchos reciben, sin conocerlos; permite añadir suscriptores sin tocar al publicador. Se hace con SNS o EventBridge.
• Desacoplamiento (el patrón más importante): los servicios se comunican a través de colas/buses, no directamente. Aporta resiliencia, escalado independiente, mantenibilidad y amortiguación de picos. Como pasar de una llamada telefónica a un WhatsApp.
• Saga: coordina una operación entre varios servicios definiendo, para cada paso, una acción compensatoria que lo deshace si algo falla, dejando el sistema coherente. Se orquesta con Step Functions (Capítulo 28).
• Todos comparten la filosofía event-driven: componentes pequeños e independientes comunicados por eventos, más resilientes, escalables y evolucionables.

¡Has terminado el Capítulo 15! Ya sabes conectar y desacoplar servicios. En el Capítulo 16 cambiamos de tema hacia la entrega de contenido y el DNS: cómo los usuarios llegan a tu aplicación de forma rápida y segura (Route 53, CloudFront, certificados SSL y WAF).