Tanquem el capítol de missatgeria ajuntant les peces (SQS, SNS, EventBridge) en els grans patrons d’arquitectura que habiliten. Més que serveis concrets, aquí parlem de formes de dissenyar sistemes que són robustos, flexibles i escalables. Entendre aquests patrons et converteix en arquitecte, no només en usuari de serveis.

Ja ho vam veure amb SNS (subcapítol 15.2): un publicador emet un missatge i molts subscriptors el reben, sense que el publicador sàpiga qui són.

La idea de fons: qui emet l’esdeveniment no coneix ni li importa qui el rebrà. Això permet afegir nous subscriptors sense tocar el publicador.

Exemple: avui, quan hi ha una nova comanda, avises a facturació i inventari. Demà, màrqueting vol assabentar-se també per enviar ofertes. Amb pub/sub, només afegeixes un subscriptor al topic; el servei de comandes no es toca. El sistema creix sense trencar el que ja existeix.

S’implementa amb SNS (difusió simple) o EventBridge (enrutament intel·ligent).

És potser el patró més important de tot el capítol. Desacoblar significa que els components d’un sistema no depenen directament els uns dels altres: es comuniquen a través d’un intermediari (una cua o un bus), no «cridant-se» entre ells.

Els avantatges del desacoblament (que ja vam veure amb SQS, subcapítol 15.1):

• Resiliència: si un component falla, els altres segueixen funcionant; els missatges esperen.
• Escalat independent: pots escalar cada component per separat segons la seva càrrega.
• Mantenibilitat: pots canviar, actualitzar o reemplaçar un component sense afectar els altres (mentre respecti el format dels missatges).
• Amortiment de pics: la cua absorbeix les allaus de tràfic.

Analogia: un sistema acoblat és com una conversa telefònica: ambdós han d’estar disponibles al mateix temps; si un no contesta, no hi ha comunicació. Un sistema desacoblat és com enviar un missatge de WhatsApp: l’envies i segueixes amb la teva vida; l’altra persona el llegeix quan pot. Molt més flexible i resistent.

El desacoblament s’aconsegueix amb cues (SQS), notificacions (SNS) i busos d’esdeveniments (EventBridge): totes les peces d’aquest capítol.

Aquest és més avançat, però convé conèixer-lo. Sorgeix d’un problema real: com coordines una operació que afecta diversos serveis, quan algun pot fallar a mig fer?

Imagina una compra que implica tres passos en tres serveis diferents:

Què passa si el pas 1 (cobrament) té èxit, però el pas 2 (inventari) falla perquè no hi ha estoc? Has cobrat al client per un producte que no pots enviar. En un sol sistema faries servir una «transacció» que ho desfà tot de cop, però aquí són serveis separats: no hi ha una transacció única que els abraci.

Una saga descompon l’operació en una seqüència de passos, on cada pas té definida una acció compensatòria (com desfer-lo). Si un pas falla, s’executen les compensacions dels passos anteriors en ordre invers, deixant el sistema coherent.

Analogia: una saga és com una reserva de viatge amb vol, hotel i cotxe. Si reserves el vol i l’hotel, però no hi ha cotxes disponibles, no et quedes amb un vol i un hotel inútils: el sistema cancel·la (compensa) el vol i l’hotel per deixar-te com al principi. Cada reserva sap com cancel·lar-se.

A AWS, les sagues s’orquestren sovint amb Step Functions (ho veurem al Capítol 28), que coordina els passos i les compensacions, recolzant-se en cues i esdeveniments per comunicar els serveis.

Tots aquests patrons comparteixen una mateixa filosofia, la de les arquitectures dirigides per esdeveniments (event-driven): en comptes d’un gran sistema monolític on tot està entrellaçat, construeixes components petits i independents que es comuniquen mitjançant missatges i esdeveniments. El resultat: sistemes més resilients (una fallada no enfonsa el conjunt), més escalables (cada peça escala pel seu compte) i més fàcils d’evolucionar (afegeixes peces sense trencar les altres).

• Pub/Sub: l’emissor publica i molts reben, sense conèixer-los; permet afegir subscriptors sense tocar el publicador. Es fa amb SNS o EventBridge.
• Desacoblament (el patró més important): els serveis es comuniquen a través de cues/busos, no directament. Aporta resiliència, escalat independent, mantenibilitat i amortiment de pics. Com passar d’una trucada telefònica a un WhatsApp.
• Saga: coordina una operació entre diversos serveis definint, per a cada pas, una acció compensatòria que el desfà si alguna cosa falla, deixant el sistema coherent. S’orquestra amb Step Functions (Capítol 28).
• Tots comparteixen la filosofia event-driven: components petits i independents comunicats per esdeveniments, més resilients, escalables i evolucionables.

Has acabat el Capítol 15! Ja saps connectar i desacoblar serveis. Al Capítol 16 canviem de tema cap a l’entrega de contingut i el DNS: com els usuaris arriben a la teva aplicació de manera ràpida i segura (Route 53, CloudFront, certificats SSL i WAF).