Seguimos en la Parte VII con el Capítulo 28: Arquitecturas serverless a escala, donde vemos cómo combinar los servicios serverless que ya conoces (Lambda, EventBridge, SQS...) en arquitecturas reales y potentes. Empezamos por el patrón más fundamental del mundo serverless moderno: las arquitecturas dirigidas por eventos (event-driven), construidas con Lambda y EventBridge. Es una forma de diseñar sistemas que escalan de forma natural y se mantienen flexibles.

Antes de combinarlas, recordemos las piezas (las vimos en la Parte IV):

• Lambda (Capítulo 14): funciones que se ejecutan cuando algo las dispara, sin gestionar servidores, y escalan solas.
• EventBridge (subcapítulo 15.3): el «bus de eventos» que recibe eventos y los enruta a quien corresponda según reglas.
• SQS, SNS (Capítulo 15): colas y notificaciones para desacoplar componentes.

En este subcapítulo las juntamos para construir un estilo de arquitectura completo.

Una arquitectura dirigida por eventos (event-driven) es aquella donde los componentes se comunican mediante eventos: «algo ha ocurrido». En vez de que un componente llame directamente a otro y espere su respuesta, emite un evento anunciando lo que pasó, y otros componentes reaccionan a ese evento si les interesa.

Analogía: una arquitectura event-driven funciona como anuncios por megafonía en un aeropuerto. Cuando «se anuncia» que un vuelo está listo para embarcar (un evento), no se llama a cada persona una por una: se hace un anuncio, y todos los interesados (los pasajeros de ese vuelo) reaccionan dirigiéndose a la puerta. Quien no va en ese vuelo, lo ignora. El que anuncia no necesita saber quién está escuchando ni cuántos son. Así, el sistema es flexible: puedes añadir más «oyentes» sin cambiar quién emite.

En el mundo serverless de AWS, este patrón se construye típicamente así:

• EventBridge es el bus por donde circulan los eventos: recibe los eventos que emiten unos componentes y los enruta (con reglas, subcapítulo 15.3) a los que deben reaccionar.
• Lambda son las funciones que reaccionan a esos eventos: cuando llega un evento que les corresponde, EventBridge las dispara y hacen su trabajo.

Cada Lambda hace una cosa concreta y se ejecuta solo cuando llega su evento, escalando automáticamente según cuántos eventos lleguen.

Recuerda el desacoplamiento que vimos con la mensajería (subcapítulo 15.4). Quien emite el evento no necesita saber quién lo procesará ni cuántos lo harán. Esto significa que puedes añadir nuevas reacciones sin tocar el componente que emite. ¿Quieres que, además, se envíe una notificación cuando se crea un pedido? Añades una Lambda nueva que escuche ese evento, sin modificar nada de lo existente.

Como cada reacción es una Lambda independiente que escala sola (Capítulo 14), el sistema escala de forma natural con la carga. Si llegan 10 eventos o 10.000, cada Lambda se multiplica según haga falta, en paralelo. No hay que planificar capacidad.

Es muy fácil hacer evolucionar el sistema: añadir, quitar o cambiar reacciones a eventos sin reescribir todo. La arquitectura crece pieza a pieza, lo que la hace ideal para sistemas que evolucionan rápido.

Si una Lambda que reacciona falla, no tumba al resto: las demás siguen procesando sus eventos. Y combinando con colas (SQS, subcapítulo 15.1), los eventos no se pierden aunque algo falle temporalmente.

⚠️ No todo son ventajas: las arquitecturas event-driven son más flexibles y escalables, pero también más difíciles de seguir y depurar (un evento desencadena reacciones en cadena por todo el sistema). Aquí es donde el trazado distribuido (X-Ray, subcapítulo 24.3) se vuelve imprescindible, para seguir el rastro de un evento a través de todas las Lambdas que dispara. Recuerda también el equilibrio entre pilares (subcapítulo 27.1): ganas en escalabilidad y flexibilidad, a cambio de algo de complejidad operativa.

Ejemplo del mundo real: una tienda online procesa un pedido con arquitectura event-driven. Cuando un cliente compra, se emite el evento «pedido creado» a EventBridge. Ese único evento dispara, en paralelo, varias Lambdas independientes: una cobra el pago, otra reserva el stock, otra envía el email de confirmación, otra notifica al almacén y otra registra la venta en analítica. Cada una hace su parte sin saber de las demás. Meses después, el equipo quiere añadir un programa de puntos de fidelidad: simplemente crean una nueva Lambda que escucha el evento «pedido creado» y suma puntos, sin tocar nada del flujo existente. El sistema escala solo en las rebajas (miles de pedidos) y es fácil de ampliar. Esa flexibilidad es la esencia del event-driven.

• En una arquitectura event-driven (dirigida por eventos), los componentes se comunican mediante eventos («algo ha ocurrido»): uno emite un evento y otros reaccionan, en vez de llamarse directamente. Como los anuncios por megafonía de un aeropuerto.
• Se construye con EventBridge como bus que enruta los eventos (por reglas) y Lambdas como funciones que reaccionan, cada una haciendo una cosa concreta y escalando sola.
• Ventajas: desacoplamiento (añades reacciones sin tocar lo existente), escalabilidad natural (cada Lambda escala sola), flexibilidad para evolucionar pieza a pieza, y resiliencia (un fallo no tumba al resto).
• ⚠️ A cambio, son más difíciles de seguir y depurar (reacciones en cadena), por lo que el trazado distribuido (X-Ray) se vuelve esencial. Es el equilibrio entre flexibilidad y complejidad.

En el siguiente subcapítulo veremos cómo coordinar procesos de varios pasos que pueden fallar, manteniendo la consistencia, con el patrón Saga.