Nell’esame AZ-204 il tema del messaging asincrono ricorre in ogni scenario di integrazione e decoupling fra componenti. Azure offre due servizi di code che risolvono problemi diversi: Azure Service Bus, broker enterprise ricco di funzionalità, e le Azure Storage Queues, code semplici basate su uno Storage Account. Saper scegliere quello giusto — e configurarne le opzioni — è esattamente ciò che l’esame verifica.

Costrutti di Azure Service Bus

Service Bus è un broker di messaggi transazionale che espone due entità principali.

Queue e Topic/Subscription

Una queue implementa il pattern point-to-point: un produttore invia, uno o più consumer competono per lo stesso messaggio (competing consumers). Un topic con le sue subscription implementa invece il publish/subscribe: lo stesso messaggio viene recapitato a più subscription indipendenti. Su ciascuna subscription puoi applicare filtri per instradare solo i messaggi rilevanti:

  • Boolean filter (TrueFilter/FalseFilter)
  • SQL filter, con espressioni su proprietà come sys.Label o proprietà applicative custom
  • Correlation filter, più efficiente perché indicizzato, ideale per match su CorrelationId o poche proprietà

La scelta del filtro corretto (Correlation quando basta un match esatto su proprietà, SQL quando serve logica più ricca) è un classico dettaglio da livello associate.

Peek-lock vs Receive-and-delete

Sono le due modalità di ricezione, ed è la distinzione più insidiosa:

  • Peek-lock (default): il messaggio viene bloccato ma non rimosso; il consumer deve chiamare CompleteMessageAsync per eliminarlo, oppure AbandonMessageAsync/DeadLetterMessageAsync. Garantisce consegna at-least-once: se il consumer va in crash prima del complete, il lock scade e il messaggio torna disponibile.
  • Receive-and-delete: il messaggio è rimosso appena letto. È più veloce ma se il consumer fallisce dopo la lettura, il messaggio è perso (consegna at-most-once).

Regola d’esame: quando lo scenario chiede di “non perdere messaggi” o processing affidabile, la risposta è peek-lock.

Dead-letter queue, sessioni, duplicate detection

Ogni queue e subscription ha una dead-letter queue (DLQ) di sistema dove finiscono i messaggi non elaborabili: superamento di MaxDeliveryCount, scadenza del TTL o dead-lettering esplicito. È il posto dove ispezionare i “poison message”.

Le sessions abilitano l’elaborazione FIFO e lo stato correlato: tutti i messaggi con lo stesso SessionId vengono consegnati ordinatamente a un singolo consumer che detiene il lock di sessione. Servono ogni volta che lo scenario richiede ordering garantito o gestione di conversazioni/stato per un’entità (es. tutti gli eventi di un ordine).

La duplicate detection scarta messaggi con lo stesso MessageId entro una finestra temporale configurabile, offrendo semantica prossima a exactly-once lato invio.

Queste tre feature — DLQ, sessions, duplicate detection — insieme a topic e transazioni sono esclusive di Service Bus (in particolare sessions e topic richiedono almeno il tier Standard).

Storage Queues: semplicità e scala

Le Storage Queues sono code HTTP/REST su uno Storage Account: economiche, con throughput molto elevato e capacità fino a circa 80 GB di messaggi accodati. Sono l’opzione giusta quando:

  • il volume è enorme e il budget contenuto
  • serve un log di messaggi persistente e ispezionabile
  • basta consegna at-least-once senza ordering, senza pub/sub, senza sessioni

Non offrono FIFO, topic/subscription, transazioni né duplicate detection. Il messaggio ha un limite di 64 KB (contro i 256 KB Standard / 100 MB Premium di Service Bus) e la deduplica/ordinamento vanno gestiti dall’applicazione.

Quando scegliere quale

  • Service Bus: ordering FIFO, pub/sub con routing, transazioni, sessioni stateful, dead-lettering, integrazione enterprise, messaggi > 64 KB.
  • Storage Queue: pipeline semplice ad alto volume, costo minimo, nessun requisito di ordinamento o routing avanzato.

Trappole tipiche d’esame

  • Scenario: serve elaborazione FIFO ordinata per cliente → risposta: Service Bus queue con sessions (SessionId), non Storage Queue, che non garantisce ordering.
  • Scenario: lo stesso evento deve raggiungere più sottosistemi indipendenti → risposta: Service Bus topic con subscription (e filtri SQL/Correlation), mai una singola Storage Queue.
  • Scenario: i messaggi non devono andare persi se il worker crasha → risposta: modalità peek-lock con Complete esplicito; receive-and-delete è la scelta sbagliata.
  • Scenario: >80 GB di messaggi accodati o milioni di messaggi a costo minimo senza ordering → risposta: Storage Queue, non Service Bus.
  • Scenario: evitare elaborazioni duplicate a fronte di reinvii dello stesso MessageId → risposta: abilitare duplicate detection su Service Bus (feature assente nelle Storage Queue).