Code vs. Topic: scegliere il pattern di messaggistica giusto in Azure Service Bus

By Mirko Peters · 2026-08-27

Bentornato sul blog di accompagnamento del podcast! Nel nostro ultimo episodio abbiamo analizzato a fondo gli elementi di base della messaggistica nel cloud. Se non hai avuto modo…

Automatically translated with AI from the original post. Read the English original

Bentornato sul blog di accompagnamento al podcast! Nel nostro ultimo episodio abbiamo approfondito gli elementi fondamentali della messaggistica nel cloud. Se non hai ancora avuto modo di ascoltarlo, non perdere l'episodio Azure Service Bus - Simply Explained. Oggi approfondiamo una delle decisioni architetturali più importanti che prenderai quando costruirai applicazioni distribuite: la scelta tra code e topic di Azure Service Bus. Capire le sfumature di questi due pattern di messaggistica ti aiuterà a progettare sistemi più resilienti, scalabili e facili da mantenere.

Introduzione ad Azure Service Bus e ai pattern di messaggistica

Man mano che le applicazioni moderne abbandonano le architetture monolitiche per passare a progetti distribuiti basati su microservizi, la necessità di una comunicazione affidabile diventa fondamentale. I servizi non possono limitarsi a basarsi su chiamate HTTP sincrone per ogni cosa: così facendo si creano forti accoppiamenti, guasti a cascata e colli di bottiglia nelle prestazioni. È qui che entrano in gioco i broker di messaggi nel cloud.

Azure Service Bus funziona come un broker di messaggi aziendale completamente gestito, che disaccoppia applicazioni e servizi. Consentendo ai produttori di inviare messaggi senza dover sapere chi sia il consumatore, o addirittura se il consumatore sia attualmente online, Azure Service Bus garantisce un'elevata disponibilità e un bilanciamento fluido dei carichi di lavoro. Tuttavia, una volta deciso di usare Azure Service Bus, ti trovi subito di fronte a una domanda progettuale fondamentale: mi serve una coda o un topic?

Che cos'è Azure Service Bus?

Prima di addentrarci nelle differenze tra code e topic, conviene chiarire cosa fa davvero Azure Service Bus. Nella sua essenza, Azure Service Bus è un broker di messaggi che archivia in modo sicuro i messaggi all'interno di uno spazio dei nomi finché un'applicazione ricevente non è pronta a elaborarli. Offre funzionalità solide come garanzie di consegna almeno una volta, gestione delle sessioni, dead-lettering e pianificazione della consegna dei messaggi.

In un ecosistema cloud, Azure Service Bus colma il divario tra i diversi componenti dell'applicazione. Che tu stia elaborando ordini e-commerce, gestendo la telemetria dell'Internet of Things (IoT) o coordinando integrazioni di pianificazione delle risorse aziendali (ERP), Service Bus fornisce la durabilità e la capacità di elaborazione asincrona necessarie per far fluire i dati senza intoppi.

Code vs. topic: la scelta architetturale di fondo

La differenza fondamentale tra code e topic si riduce al pattern di messaggistica che supportano: punto a punto contro pubblicazione/sottoscrizione. Scegliere il pattern sbagliato può portare a rifacimenti architetturali, problemi di duplicazione dei dati o colli di bottiglia nella scalabilità in una fase successiva.

Una coda offre un modello di comunicazione uno-a-uno. Quando invii un messaggio a una coda, esattamente un consumatore leggerà ed elaborerà quel messaggio. Al contrario, un topic offre un pattern di comunicazione uno-a-molti. Quando pubblichi un messaggio su un topic, questo viene distribuito a più sottoscrizioni, consentendo a più servizi downstream indipendenti di ricevere ed elaborare una copia di quello stesso identico messaggio.

La scelta tra questi due pattern dipende interamente dai requisiti di business. Hai un unico carico di lavoro che deve essere distribuito tra più istanze di lavoro per il bilanciamento del carico, oppure hai più sistemi eterogenei che devono tutti reagire a un singolo evento di business?

Approfondimento sulle code di Service Bus

Le code di Service Bus sono il cavallo di battaglia della messaggistica aziendale tradizionale. Sono progettate per scenari in cui un'attività deve essere eseguita una sola volta da un pool di worker.

Quando invii un messaggio a una coda, questo resta lì finché un ricevente non lo preleva. Per impostazione predefinita, le code applicano un ordine di consegna rigoroso First-In, First-Out (FIFO). Questo le rende ideali per architetture guidate dai comandi in cui l'ordine conta, come l'elaborazione di transazioni di pagamento o l'esecuzione di passaggi di workflow sequenziali.

Inoltre, le code eccellono nel livellamento del carico. Se la tua applicazione subisce un picco enorme di traffico, le richieste in arrivo possono accumularsi in sicurezza nella coda senza sovraccaricare le risorse di calcolo del backend. I servizi worker possono quindi prelevare i messaggi dalla coda a un ritmo sostenibile e costante.

Approfondimento su topic e sottoscrizioni

Mentre le code gestiscono la consegna semplice punto a punto, i topic aprono la strada al modello publish/subscribe (pub/sub). Un topic funge da endpoint per l'invio dei messaggi, ma da solo non può contenere messaggi senza delle sottoscrizioni.

Pensa a una sottoscrizione come a una coda virtuale collegata a un topic. Quando un messaggio viene pubblicato su un topic, una copia di quel messaggio viene recapitata a ciascuna sottoscrizione attiva. Ogni servizio consumer crea una propria sottoscrizione al topic, così può elaborare il messaggio in modo indipendente dagli altri consumer.

Prendiamo, ad esempio, l'evento di inserimento di un ordine in una piattaforma e-commerce. Quando un cliente effettua un ordine, il sistema pubblica un messaggio OrderPlaced su un topic. Il servizio di magazzino ha una sottoscrizione per aggiornare i livelli di scorta, il servizio di fatturazione ha una sottoscrizione per elaborare il pagamento e il servizio di notifica ha una sottoscrizione per inviare la ricevuta via email. Tutti e tre i sistemi ricevono l'evento contemporaneamente, senza interferire tra loro.

Filtri dei messaggi e flessibilità

Una delle funzionalità più potenti dei topic di Azure Service Bus è il filtraggio dei messaggi. In molti scenari pub/sub, un subscriber non vuole ricevere ogni singolo messaggio pubblicato su un topic; gli interessa solo un sottoinsieme specifico di dati.

Azure Service Bus consente di definire regole e filtri sulle sottoscrizioni usando una sintassi simile a SQL oppure proprietà di correlazione. Ad esempio, puoi configurare una sottoscrizione in modo che riceva solo i messaggi in cui la proprietà Region è uguale a NorthAmerica oppure in cui OrderAmount supera una determinata soglia.

Questa capacità di filtraggio mantiene leggero il traffico di rete e garantisce che i consumer a valle elaborino solo i dati pertinenti per loro, riducendo in modo significativo il carico di calcolo non necessario.

Gestione dei guasti con le dead-letter queue

Che tu usi code o topic, i sistemi distribuiti sono soggetti a guasti. Cosa succede quando un messaggio è malformato, un database a valle va offline o un'applicazione va in crash ripetutamente mentre tenta di elaborare un messaggio specifico?

Azure Service Bus gestisce questa situazione in modo efficace tramite le dead-letter queue (DLQ). Ogni coda e ogni sottoscrizione di topic dispone di una sotto-coda associata, detta dead-letter queue. Se l'elaborazione di un messaggio fallisce troppe volte (superando il numero massimo di consegne) o il messaggio scade, Service Bus lo sposta automaticamente nella DLQ.

Questo meccanismo isola i cosiddetti « messaggi velenosi » affinché non blocchino la pipeline di elaborazione principale. Gli ingegneri possono ispezionare la DLQ, analizzare il motivo del guasto, correggere il bug sottostante e quindi reinviare il messaggio al flusso di lavoro principale per un'elaborazione corretta.

Best practice per la progettazione di applicazioni distribuite

Per sfruttare al massimo la tua implementazione di Azure Service Bus, è fondamentale seguire le best practice architetturali consolidate:

• Isola gli ambienti: usa namespace di Service Bus separati per gli ambienti di sviluppo, staging e produzione, così da impedire che i guasti si propaghino da un ambiente all'altro.
• Implementa l'Infrastructure as Code: definisci code, topic, sottoscrizioni e filtri usando template ARM, Bicep o Terraform, per garantire deployment coerenti.
• Imposta criteri di conservazione appropriati: configura il time-to-live (TTL) dei messaggi e la durata dei lock in base alle reali esigenze di business, anziché affidarti ai valori massimi predefiniti.
• Monitora e configura gli avvisi: usa Azure Monitor e Application Insights per tenere sotto controllo metriche come il numero di messaggi, i messaggi attivi nella dead-letter queue e la latenza del server.

Conclusione: scegliere il pattern giusto per la tua architettura

Scegliere il pattern di messaggistica corretto in Azure Service Bus è fondamentale per costruire applicazioni cloud resilienti e scalabili. Usa le code quando ti serve un meccanismo affidabile uno-a-uno punto a punto per bilanciare i carichi ed elaborare le attività in sequenza. Scegli topic e sottoscrizioni quando ti serve un modello publish/subscribe per trasmettere eventi a più sistemi indipendenti.

Per ascoltare altre discussioni su architettura cloud, sicurezza e pattern di sviluppo moderni, non perdere l'episodio completo: Azure Service Bus - Simply Explained. Integrare correttamente questi pattern di messaggistica garantirà che le tue applicazioni cloud restino robuste, adattabili e pronte a scalare con qualsiasi carico di lavoro.