Quick Note — Recommend a Messaging Architecture
AZ-305 › Unit 4: Design infrastructure solutions › Design an application architecture › Recommend a messaging architecture
Quick Note — Recommend a Messaging Architecture
An e-commerce platform processes orders with a chain of services: order capture, inventory, fulfilment, billing, notification. The architect's first design uses HTTP calls between services — synchronous, "simple", and beautiful in the architecture diagram. The first Black Friday it falls over: the billing service slows down for an unrelated reason, every upstream service backs up, and within ten minutes nothing accepts new orders. The fix is one architectural change: replace the HTTP chain with an async messaging path through Service Bus.…
Retrieval target
- Recommend a Messaging Architecture
- Closed-book recall
- 5 minutes
- Open the full lesson after a miss
Decision anchors
| Prompt | Compact answer |
|---|---|
Azure Service Bus | Microsoft's enterprise messaging service — supports both queues (point-to-point) and topics + subscriptions (pub/sub). Designed for command-style messaging with strict delivery guarantees: ordered FIFO via sessions, transactional sends, dead-letter queues, scheduled delivery, duplicate detection. Tiers: Standard (multi-tenant) and Premium (dedicated capacity, VNet, larger messages). |
Service Bus Queue vs Storage Queue | Service Bus Queue — enterprise features: sessions (FIFO), DLQ, peek-lock, transactions, max 256 KB (1 MB Premium) message size, max queue size 80 GB. Storage Queue — simple, cheap, REST-only; 64 KB messages, unlimited queue size (up to storage account cap), no sessions / DLQ / transactions.… |
Topic + Subscription (Service Bus) | Pub/sub primitive: publisher sends to a Topic, every Subscription under the topic gets a copy filtered by a SQL-like rule. Subscriptions are independent queues — multiple consumers can each get the messages they care about. Use for fan-out patterns (one event → many handlers). Up to subscriptions per topic. |
Dead-Letter Queue (DLQ) | A sub-queue on every Service Bus queue / subscription that receives messages the system couldn't deliver — exceeded max delivery count, expired TTL, or explicitly dead-lettered by app code. Lets you isolate poison messages without blocking the main queue. Inspect, replay, or discard from DLQ via the SDK. Always monitor DLQ depth as an alert signal. |
Read the answers once, then cover the right-hand column and reconstruct each one from the prompt. A useful answer names the requirement, the recommended control or service boundary, and the nearest alternative it rejects. If you can only recognize the answer after seeing it, retrieval is not yet secure.
Ninety-second explanation
Without notes, explain:
- What requirement signals this learning objective rather than a neighbouring one?
- Which two solution families are most likely to be compared?
- Which hard constraint eliminates the strongest distractor?
- What identity, network, data, or failure boundary must appear in the design?
- Which operational test would prove the recommendation works?
Then compare your explanation with the full lesson. Record the missing decision rule—not merely the missed product name—in your error log.
When to open the full lesson
Open the curriculum-linked lesson when you cannot explain a comparison, when a scenario depends on a numeric limit or SKU feature, or when the service is on a retirement path. Use current Microsoft Learn documentation for availability, limits, pricing, naming, and migration milestones; the quick note is intentionally compact.
Source and freshness
Derived from the linked AZ-305 lesson and retrieval deck, grounded in both attached course sources. Reviewed 2026-08-02. Current Microsoft documentation controls changing product contracts.