Messaging Architecture
Azure Service Bus, Queue Storage, and message patterns — design reliable asynchronous communication between services with guaranteed delivery and ordering.
Why messaging architecture matters
Messaging is how services talk without waiting for each other. Instead of Service A calling Service B directly (and waiting), Service A puts a message in a queue, and Service B processes it when ready.
This decoupling means: if Service B goes down, messages wait safely in the queue. If Service B is slow, messages buffer. If you need 10x throughput, add more consumers.
Two Azure services: Queue Storage (simple, cheap, high volume) and Service Bus (enterprise-grade with ordering, sessions, transactions, dead-lettering).
Queue Storage vs Service Bus
| Factor | Queue Storage | Service Bus Queues |
|---|---|---|
| Protocol | HTTP/HTTPS (REST) | AMQP 1.0, HTTP/HTTPS |
| Max message size | 64 KB | 256 KB (Standard) / 100 MB (Premium) |
| Max queue size | Unlimited (storage account limit) | 1-80 GB |
| Message ordering | Not guaranteed (best-effort FIFO) | Guaranteed FIFO (with sessions) |
| Duplicate detection | No | Yes (built-in) |
| Dead-letter queue | No — poison messages need custom handling | Yes — automatic dead-letter sub-queue |
| Transactions | No | Yes — atomic send/complete across messages |
| Sessions | No | Yes — group related messages for ordered processing |
| Topics (pub-sub) | No — queues only | Yes — topics with subscriptions and filters |
| Cost | Very low (~$0.0004/10K operations) | Higher (~$0.05/million operations Premium) |
| Best for | Simple queuing, high volume, cost-sensitive | Enterprise messaging, ordering, transactions, pub-sub |
🚀 Marcus’s messaging design: NovaSaaS uses Service Bus:
- Queues for order processing (guaranteed FIFO with sessions per customer)
- Topics for notifications (one order event fans out to: billing, inventory, email, analytics)
- Dead-letter queue catches poison messages for investigation
- Duplicate detection prevents double-processing when retries occur
🏗️ Priya’s cost-conscious choice: GlobalTech’s non-critical log ingestion uses Queue Storage — millions of messages per day at minimal cost, ordering doesn’t matter, messages are simple JSON.
Exam tip: Queue Storage vs Service Bus — keyword signals
Queue Storage: “simple queuing,” “high volume,” “cost-sensitive,” “messages under 64 KB,” “no ordering needed”
Service Bus: “enterprise,” “guaranteed ordering,” “FIFO,” “transactions,” “dead-letter,” “pub-sub,” “topics,” “sessions,” “duplicate detection”
If ANY of the Service Bus keywords appear in the scenario, choose Service Bus.
Service Bus Premium vs Standard
| Factor | Standard | Premium |
|---|---|---|
| Throughput | Shared (variable) | Dedicated (predictable) |
| Message size | 256 KB | 100 MB |
| VNet integration | No | Yes (private endpoints) |
| Geo-DR | No | Yes (metadata replication) |
| Best for | Dev/test, moderate workloads | Production, compliance, high throughput |
Common messaging patterns
| Pattern | Description | Implementation |
|---|---|---|
| Competing consumers | Multiple consumers process from one queue | Scale out processing by adding consumers |
| Fan-out | One message triggers multiple actions | Service Bus topic with multiple subscriptions |
| Load levelling | Buffer burst traffic | Queue absorbs spikes, consumers process at steady rate |
| Saga pattern | Distributed transactions across services | Choreography via messages or orchestration via Durable Functions |
Knowledge check
🚀 NovaSaaS processes customer orders that must be handled in exact sequence per customer. If a message can't be processed after 3 attempts, it should be moved aside for investigation without blocking other orders. Which service should Marcus recommend?
🏦 FinSecure Bank processes loan applications. Each application must be reviewed by both the credit team AND the compliance team simultaneously. High-value loans (over €1M) must also be routed to the executive review team. All teams process independently. Which messaging pattern should Elena recommend?
Next up: Messages are commands. Events are notifications — Event-Driven Architecture.