En el subcapítol anterior vam veure SQS, on un missatge va a un consumidor que el processa. Però a vegades vols el contrari: que un mateix missatge arribi a molts destinataris alhora. Per això existeix SNS (Simple Notification Service), el servei de notificacions d’AWS. És el complement perfecte de les cues.

Imagina que en una botiga es realitza una comanda, i quan això passa vols que diversos sistemes se n’assabentin al mateix temps:

• El servei de facturació (per generar la factura).
• El servei d’inventari (per descomptar l’estoc).
• El servei d’emails (per avisar el client).
• El servei d’analítica (per a les estadístiques).

Amb una cua SQS, el missatge aniria a un consumidor. Aquí volem que l’avís «hi ha una nova comanda» arribi a tots alhora. Això és exactament el que fa SNS.

SNS funciona amb el model publicador/subscriptor (pub/sub):

• Un publicador envia un missatge a un topic (tema).
• Tots els subscriptors d’aquell topic reben una còpia del missatge, alhora.

• Topic (tema): el «canal» al qual s’envien els missatges (ex. nova-comanda).
• Subscripció: cada destinatari es subscriu al topic per rebre els seus missatges.

Analogia: SNS és com una llista de difusió o un canal de ràdio. El locutor (publicador) emet un missatge una vegada, i tots els que estan subscrits al canal el reben simultàniament. El locutor no necessita saber quants oients hi ha ni qui són.

És fonamental no confondre’ls:

En resum: SQS reparteix feina (un missatge, un treballador); SNS difon avisos (un missatge, tothom assabentat).

Un topic SNS pot tenir molts tipus de subscriptors, cosa que el fa molt versàtil:

• Una funció Lambda (perquè reaccioni a l’esdeveniment, Capítol 14).
• Una cua SQS (molt important! ho veurem tot seguit).
• Un email (SNS envia un correu).
• Un SMS (un missatge de text a un mòbil).
• Un endpoint HTTP/HTTPS (avisar un altre sistema via web).

Aquí hi ha la combinació més potent, i una de les arquitectures més utilitzades a AWS: el patró fan-out («abanic»). Consisteix a posar un topic SNS que difon a diverses cues SQS, una per a cada servei.

Per què és tan bo combinar-los? Perquè suma el millor dels dos:

• SNS difon l’avís a tots els serveis alhora (un a molts).
• Cada cua SQS dona al seu servei la resiliència i el coixí que vam veure al subcapítol 15.1: si el servei d’inventari cau, els seus missatges esperen a la seva cua sense perdre’s, mentre la resta de serveis continuen funcionant amb normalitat.

Exemple del món real: a la botiga, es publica «nova comanda» al topic SNS. Arriba instantàniament a les cues de facturació, inventari, emails i analítica. El servei d’analítica està en manteniment (caigut), però els seus missatges s’acumulen a la seva cua i els processarà quan torni. Mentrestant, facturació, inventari i emails processen els seus sense problema. Cap comanda es perd i cap servei bloqueja els altres.

Aquest patró fan-out és la base de moltes arquitectures dirigides per esdeveniments (ho veurem al subcapítol 15.4 i al Capítol 28).

• SNS és el servei de notificacions amb model publicador/subscriptor: un missatge enviat a un topic arriba a tots els seus subscriptors alhora (un a molts).
• Diferència clau amb SQS: SQS reparteix feina (un missatge → un consumidor); SNS difon avisos (un missatge → tots els subscriptors). Com una llista de difusió o un canal de ràdio.
• Els subscriptors poden ser Lambdas, cues SQS, emails, SMS o endpoints HTTP.
• El patró fan-out (SNS → diverses cues SQS) combina el millor de tots dos: difusió a tots els serveis + resiliència i coixí de cada cua. És una de les arquitectures més utilitzades.

Al següent subcapítol veurem un servei d’esdeveniments més modern i flexible que amplia aquestes idees: EventBridge.