Perché disaccoppiare

In un’architettura tightly coupled i componenti si chiamano in modo sincrono: se il consumer rallenta o cade, il producer si blocca e l’errore si propaga a monte. Il decoupling inserisce un livello intermedio — una coda o un event bus — che assorbe le differenze di ritmo fra chi produce e chi consuma il lavoro. Il risultato è fault tolerance: un componente può fallire senza trascinare gli altri, e può essere scalato o sostituito in modo indipendente. All’esame SAA-C03 questi scenari sono ricorrenti: dato un requisito di resilienza o di gestione dei picchi, devi scegliere fra messaging (SQS), pub/sub (SNS) ed event routing (EventBridge).

Amazon SQS: la coda come buffer

Amazon SQS è una coda gestita che disaccoppia producer e consumer con un modello pull: i consumer fanno polling e la coda trattiene i messaggi in modo durevole. Serve soprattutto ad assorbire i picchi (load leveling): il producer scrive alla velocità del traffico, i consumer processano al ritmo sostenibile, evitando di sovraccaricare il backend.

Due tipi:

  • Standard: throughput quasi illimitato, ordine best-effort e consegna at-least-once (possibili duplicati). Richiede consumer idempotenti.
  • FIFO: ordine garantito ed exactly-once processing, ma throughput limitato. Usalo solo quando l’ordine o l’assenza di duplicati è un requisito reale.

Concetti chiave: il visibility timeout nasconde un messaggio agli altri consumer mentre viene elaborato; se il consumer non lo cancella entro il timeout, il messaggio torna visibile e viene riprocessato. Se questo supera la soglia maxReceiveCount, il messaggio finisce in una dead-letter queue (DLQ): una coda separata dove isolare i poison message per analizzarli, senza bloccare il flusso principale.

Fan-out con SNS e routing con EventBridge

Quando lo stesso evento deve raggiungere più destinatari serve un modello pub/sub. Amazon SNS è un servizio push a topic: un publisher invia un messaggio e SNS lo consegna a tutti i subscriber. Il pattern fan-out classico è SNS verso più code SQS: ogni servizio a valle ha la propria coda, processa in modo indipendente e conserva i propri messaggi anche se un altro consumer è fermo. SNS supporta filtri per sottoscrizione, così ogni coda riceve solo i messaggi che la riguardano.

Amazon EventBridge è un event bus per architetture event-driven con routing content-based: le rules valutano il contenuto dell’evento (pattern matching sui campi) e lo instradano verso i target giusti (Lambda, SQS, SNS, Step Functions e altri). Rispetto a SNS aggiunge l’integrazione nativa con eventi di molti servizi AWS e SaaS di terze parti, uno schema registry ed eventi schedulati. Regola pratica: SNS per fan-out ad alto throughput verso poche destinazioni note; EventBridge quando serve filtrare o instradare per contenuto e integrare sorgenti eterogenee.

Auto Scaling e resilienza

Il disaccoppiamento dà il meglio con lo scaling elastico. Un Auto Scaling group di istanze Amazon EC2 (o un consumer serverless come Lambda) può crescere in base alla profondità della coda: una policy di target tracking sul backlog aggiunge consumer quando i messaggi si accumulano e li rimuove quando la coda si svuota, pagando solo la capacità necessaria. Distribuendo le istanze su più Availability Zone si ottiene alta disponibilità: se una AZ cade, i messaggi restano nella coda durevole e vengono processati dalle istanze superstiti. È questa combinazione — coda durevole, consumer stateless e scalabili, deploy multi-AZ — a realizzare la fault tolerance richiesta negli scenari d’esame. Ricorda che il passing score è 700/1000.

Trappole tipiche d’esame

  • Picchi di traffico che sovraccaricano il database → Amazon SQS come buffer: la coda fa load leveling; distrattori come “aumenta la dimensione dell’istanza RDS” curano il sintomo, non il disaccoppiamento.
  • Stesso messaggio a più sistemi indipendenti → SNS fan-out verso più code SQS: una singola coda letta da più consumer NON è fan-out (i consumer si “rubano” i messaggi); serve una coda per destinatario sottoscritta al topic.
  • Ordine rigoroso o niente duplicati → SQS FIFO: scegliere Standard “perché più veloce” è la trappola quando il requisito parla di ordine o exactly-once.
  • Messaggi che falliscono di continuo e bloccano l’elaborazione → dead-letter queue: isola i poison message dopo maxReceiveCount; aumentare solo il visibility timeout non risolve il fallimento ripetuto.
  • Instradare eventi in base al contenuto o integrare eventi di servizi AWS/SaaS → Amazon EventBridge: SNS filtra ma non offre il content routing ricco né l’integrazione nativa di sorgenti eterogenee.
  • Scalare i consumer in base al lavoro arretrato → Auto Scaling sulla profondità della coda: scalare sulla CPU può non riflettere il backlog reale; usa la metrica dei messaggi visibili.