This content originally appeared on DEV Community and was authored by Harnoor Puniyani
When I first used Azure Service Bus, I thought it was “just a queue.” It’s much more: routing, ordering, retries, DLQ, and transactions—useful for high‑volume, near real‑time, stateful integrations.
Service Bus in 60 seconds
Queues: point‑to‑point
Topics & Subscriptions: pub/sub with SQL filters on message properties
Sessions: FIFO per key (keeps order for a customer/order)
Retries & DLQ: automatic retries; poison messages move to DLQ
Extras: duplicate detection, scheduled delivery, deferral, transactions
Using Service Bus in Modern Architectures
I’m highlighting three common use cases that are easily handled with queues and topics.
1) Event‑Driven Architecture with Routed Messages
Scenario: accept requests, fan‑out by properties, and keep downstreams isolated.
For an asynchronous inbound flow, expose a Topic where a client can send messages. Based on custom metadata (for example, a type property), if type is ERP_PRODUCT_MASTER it goes to the product subscription; if type is ERP_CUSTOMER_MASTER it goes to the customer subscription. Messages are filtered into their respective subscriptions. If a subscription needs to receive all events, omit the filter—product events will go to both the logs subscription and the product subscription, and similarly for customer events.
2) Sessions as a Keyed Index (the “HashMap” trick)
Docs focus on sessions for strict ordering. You can also use a session as a single‑item, keyed bucket for quick lookups.
Imagine a transactional flow where you store the data in Service Bus and keep only a reference to that message in the client system. When the client later sends the reference, you need to fetch the message from Service Bus. The simplest method is to use sessions:
Set
SessionIdto a business key (e.g.,REF-123)Store one message per session (acts like key → value)
The consumer accepts the session with that ID to fetch the message directly
Benefits:
No scanning/deferring through many messages
Avoids long lock durations while you hunt for the right payload
3) Transactional Atomicity
Goal: process a batch atomically; complete only on success.
Receive in peek‑lock, do work, then
completeOn transient failure:
abandon(retry)On business retry later:
defer(preserve for targeted pickup)On poison: let it exceed max deliveries → DLQ
Notes:
Tune
MaxDeliveryCountto balance retries vs. fast DLQRenew locks if processing may exceed
LockDurationMake handlers idempotent (at‑least‑once delivery)
Ops and Security Tips
Enable duplicate detection if producers can retry sends
Alert on DLQ > 0, retry spikes, handler failures
Prefer Premium + private endpoints/VNet where possible
Use Managed Identities/App Registrations over SAS
Log
CorrelationIdand business keys; avoid payload logging
Thanks for reading. If you want configuration‑focused examples (Functions/Logic Apps, sessions, filters, or DLQ replay), let me know.
This content originally appeared on DEV Community and was authored by Harnoor Puniyani
Harnoor Puniyani | Sciencx (2025-10-18T09:25:39+00:00) Understanding Azure Service Bus: How to Manage Routing, Sessions, and Atomicity. Retrieved from https://www.scien.cx/2025/10/18/understanding-azure-service-bus-how-to-manage-routing-sessions-and-atomicity/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.