What's changed: Deepened AZ-305 Chapter 4 (added comparison tables, scenarios, FAQs, exam traps, deep-dive paragraphs to each section; localized figures to Japanese)
4.2Designing App Integration and Messaging
Understand loosely coupled integration—Service Bus/Event Grid/Event Hubs, API Management, Logic Apps, and Azure Cache for Redis. Decouple components and integrate at scale.
Scalable design starts with loose coupling. Choose among Service Bus, Event Grid, and Event Hubs by purpose.
4.2.1Messaging and integration
- Service Bus: enterprise messaging (queues/topics; ordering/transactions/dead-letter).
- Event Grid: reactive event delivery (pub/sub, state-change notifications).
- Event Hubs: high-volume streaming ingestion (telemetry/big data).
- API Management/Logic Apps/Redis: API gateway / no-code integration / low-latency cache.
Common on AZ-305: ordered/transactional enterprise messaging = Service Bus, state-change event notifications = Event Grid, high-volume telemetry stream = Event Hubs, API publishing gateway = API Management, no-code workflows = Logic Apps. Distinguishing the three messaging services is key.
Remember: business messages needing reliable ordering = Service Bus; ingesting massive IoT/log streams per second = Event Hubs; reacting to resource state changes = Event Grid.
AZ-305 integration design probes "distinguishing messages vs events vs streams and decoupling with the right service." Service Bus is a message-oriented enterprise platform with queues (1:1) and topics/subscriptions (pub/sub), rich in reliability features—FIFO (sessions), duplicate detection, transactions, dead-letter queues, scheduled delivery—used for business messages (orders, payments) needing reliable, ordered, lossless processing. Event Grid does reactive delivery of events (lightweight "something happened" state-change notifications), pub/subbing Azure resource events or custom topics to Functions/Logic Apps/webhooks for near-real-time serverless reactions. Event Hubs specializes in high-volume ingestion of streams (telemetry/logs/IoT), handling high throughput with partitions and consumer groups, Kafka-compatible, with Capture to land into Blob/Data Lake. As front-ends or integration, combine API Management (gateway for published APIs—auth/rate limiting/versioning/transformation/developer portal), Logic Apps (no-code workflow integration with many connectors), and Azure Cache for Redis (low-latency cache, session/rate-limit store). The key is to pick among the three messaging services along "one-at-a-time reliable = Service Bus," "react to state change = Event Grid," "per-second high-volume stream = Event Hubs," decoupling for scalability.
| Type | Service | Typical use case |
|---|---|---|
| Message (business) | Service Bus | Orders/payments; ordering/transactions/DLQ |
| Event (state change) | Event Grid | React to resource changes; pub/sub |
| Stream (high-volume) | Event Hubs | IoT/log telemetry ingestion |
| API publishing/integration | API Management / Logic Apps | Gateway / no-code integration |
Scenario: For an e-commerce site, (1) process orders reliably in order, (2) notify related services when inventory changes, and (3) analyze massive clickstreams from all users. → (1) Service Bus (queue + sessions for ordering, DLQ for failure recovery), (2) Event Grid (pub/sub inventory-change events to multiple subscribers), (3) Event Hubs (ingest per-second clicks, Capture to Data Lake). Front public APIs with API Management.
FAQ: Service Bus vs Event Grid vs Event Hubs? For "reliable, one-at-a-time business messages needing ordering/transactions," Service Bus. For "lightweight reaction to something happening" (pub/sub of resource/custom events), Event Grid. For "ingest millions/sec of telemetry/logs for later analysis," Event Hubs. Identify message vs event vs stream from the question.
Exam trap: Choosing Event Hubs for "business messages needing ordering/transactions" is wrong—Event Hubs is for high-volume stream ingestion; business-message reliability (session ordering/DLQ/transactions) is Service Bus. Likewise, doing "serverless reaction to resource state changes" with Service Bus is inefficient—Event Grid fits.
4.2.2Section summary
- Messaging = Service Bus (business) / Event Grid (events) / Event Hubs (streams)
- Integration = API Management / Logic Apps / Redis
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Design business messaging needing ordering, transactions, and dead-lettering (e.g., order processing). What?
Q2. Ingest massive per-second telemetry streams from millions of devices. What?
Q3. Apply auth, throttling, and versioning centrally to multiple published APIs. What?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.