Seguim a la Part VII amb el Capítol 28: Arquitectures serverless a escala, on veiem com combinar els serveis serverless que ja coneixes (Lambda, EventBridge, SQS...) en arquitectures reals i potents. Comencem pel patró més fonamental del món serverless modern: les arquitectures dirigides per esdeveniments (event-driven), construïdes amb Lambda i EventBridge. És una manera de dissenyar sistemes que escalen de forma natural i es mantenen flexibles.

Abans de combinar-les, recordem les peces (les vam veure a la Part IV):

• Lambda (Capítol 14): funcions que s’executen quan alguna cosa les dispara, sense gestionar servidors, i escalen soles.
• EventBridge (subcapítol 15.3): el «bus d’esdeveniments» que rep esdeveniments i els enruta a qui correspongui segons regles.
• SQS, SNS (Capítol 15): cues i notificacions per desacoblar components.

En aquest subcapítol les ajuntem per construir un estil d’arquitectura complet.

Una arquitectura dirigida per esdeveniments (event-driven) és aquella on els components es comuniquen mitjançant esdeveniments: «alguna cosa ha passat». En comptes que un component cridi directament a un altre i esperi la seva resposta, emet un esdeveniment anunciant el que ha passat, i altres components reaccionen a aquest esdeveniment si els interessa.

Analogia: una arquitectura event-driven funciona com anuncis per megafonia en un aeroport. Quan «s’anuncia» que un vol està llest per embarcar (un esdeveniment), no es crida cada persona una per una: es fa un anunci, i tots els interessats (els passatgers d’aquell vol) reaccionen dirigint-se a la porta. Qui no va en aquell vol, ho ignora. Qui anuncia no necessita saber qui està escoltant ni quants són. Així, el sistema és flexible: pots afegir més «oients» sense canviar qui emet.

Al món serverless d’AWS, aquest patró es construeix típicament així:

• EventBridge és el bus per on circulen els esdeveniments: rep els esdeveniments que emeten uns components i els enruta (amb regles, subcapítol 15.3) als que han de reaccionar.
• Lambda són les funcions que reaccionen a aquests esdeveniments: quan arriba un esdeveniment que els correspon, EventBridge les dispara i fan la seva feina.

Cada Lambda fa una cosa concreta i s’executa només quan arriba el seu esdeveniment, escalant automàticament segons quants esdeveniments arribin.

Recorda el desacoblament que vam veure amb la missatgeria (subcapítol 15.4). Qui emet l’esdeveniment no necessita saber qui el processarà ni quants ho faran. Això significa que pots afegir noves reaccions sense tocar el component que emet. Vols que, a més, s’enviï una notificació quan es crea una comanda? Afegixes una Lambda nova que escolti aquest esdeveniment, sense modificar res de l’existent.

Com que cada reacció és una Lambda independent que escala sola (Capítol 14), el sistema escala de forma natural amb la càrrega. Si arriben 10 esdeveniments o 10.000, cada Lambda es multiplica segons calgui, en paral·lel. No cal planificar capacitat.

És molt fàcil fer evolucionar el sistema: afegir, treure o canviar reaccions a esdeveniments sense reescriure-ho tot. L’arquitectura creix peça a peça, cosa que la fa ideal per a sistemes que evolucionen ràpid.

Si una Lambda que reacciona falla, no tomba la resta: les altres continuen processant els seus esdeveniments. I combinant amb cues (SQS, subcapítol 15.1), els esdeveniments no es perden encara que alguna cosa falli temporalment.

⚠️ No tot són avantatges: les arquitectures event-driven són més flexibles i escalables, però també més difícils de seguir i depurar (un esdeveniment desencadena reaccions en cadena per tot el sistema). Aquí és on el traçat distribuït (X-Ray, subcapítol 24.3) es torna imprescindible, per seguir el rastre d’un esdeveniment a través de totes les Lambdas que dispara. Recorda també l’equilibri entre pilars (subcapítol 27.1): guanyes en escalabilitat i flexibilitat, a canvi d’una mica de complexitat operativa.

Exemple del món real: una botiga online processa una comanda amb arquitectura event-driven. Quan un client compra, s’emet l’esdeveniment «comanda creada» a EventBridge. Aquest únic esdeveniment dispara, en paral·lel, diverses Lambdas independents: una cobra el pagament, una altra reserva l’estoc, una altra envia el correu de confirmació, una altra notifica al magatzem i una altra registra la venda en analítica. Cadascuna fa la seva part sense saber de les altres. Mesos després, l’equip vol afegir un programa de punts de fidelitat: simplement creen una nova Lambda que escolta l’esdeveniment «comanda creada» i suma punts, sense tocar res del flux existent. El sistema escala sol a les rebaixes (milers de comandes) i és fàcil d’ampliar. Aquesta flexibilitat és l’essència de l’event-driven.

• En una arquitectura event-driven (dirigida per esdeveniments), els components es comuniquen mitjançant esdeveniments («alguna cosa ha passat»): un emet un esdeveniment i altres reaccionen, en comptes de cridar-se directament. Com els anuncis per megafonia d’un aeroport.
• Es construeix amb EventBridge com a bus que enruta els esdeveniments (per regles) i Lambdas com a funcions que reaccionen, cadascuna fent una cosa concreta i escalant sola.
• Avantatges: desacoblament (afegeixes reaccions sense tocar l’existent), escalabilitat natural (cada Lambda escala sola), flexibilitat per evolucionar peça a peça, i resiliència (una fallada no tomba la resta).
• ⚠️ A canvi, són més difícils de seguir i depurar (reaccions en cadena), per això el traçat distribuït (X-Ray) es torna essencial. És l’equilibri entre flexibilitat i complexitat.

Al següent subcapítol veurem com coordinar processos de diversos passos que poden fallar, mantenint la consistència, amb el patró Saga.