API Management, events, and messages
Where it sits in the route
This module follows SDK data access and application identity. It gives the learner a decision model for synchronous APIs and asynchronous integration before observability and DevOps deployment.
Prerequisites and outcomes
Know HTTP methods/status codes, REST, JSON, tokens, retries, idempotency, and producer/consumer vocabulary. You should be able to trace an API call through a gateway, distinguish notification from stream from work message, and select a service from delivery needs.
Concept sequence and relationships
API Management publishes an API contract, applies gateway policies, and forwards permitted requests to a backend. The backend still owns application behavior and may authorize again. Event Grid publishes an occurrence to subscribers; Event Hubs appends high-volume events to partitions for consumers; Service Bus and Queue Storage carry work messages that consumers process and complete.
An event is not a command: the publisher does not require a specific action from every subscriber. A stream is not a queue: consumers track their position rather than removing one work item. Service Bus and Queue Storage are not interchangeable when transactions, dead-lettering, ordering, or richer delivery behavior matters. Every handler must tolerate retries and avoid duplicate side effects.
Worked scenario
Expose POST /orders through APIM and validate the contract at the gateway. After persistence, publish OrderCreated through Event Grid
for independent notifications. Send thumbnail work to Service Bus when delivery and retry control matter; send simple low-cost background
work to Queue Storage. Send clickstream telemetry to Event Hubs for partitioned consumers.
Distinctions and troubleshooting
- Gateway rejection means the request did not reach the backend; backend rejection means the gateway passed it.
- Event Grid delivery failure concerns subscriber notification; Event Hubs lag concerns consumer position; message dead-lettering concerns work that could not be completed.
- Duplicate processing is a consumer idempotency problem, not proof that the sender sent one logical event twice.
Conceptual checkpoint
For four requirements—webhook notification, analytics stream, order command, and simple worker task—choose the service and justify delivery, retry, ordering, and consumer state. Draw the API/gateway/backend and producer/service/consumer boundaries.
Hands-on / what to try
Read a configuration exercise containing one API route and four integration requirements. Predict the selected service, boundary, failure signal, and retry action. Change one requirement from notification to command, revise the design, and remove the exercise data. This is a static procedure and not live-verified.
Sources and re-audit
- AZ-204 API and messaging objectives, skills measured 2026-01-14; checked 2026-08-31.
- API Management concepts, checked 2026-08-31.
- Event Grid overview, Event Hubs overview, and Service Bus overview, checked 2026-08-31.
Re-audit when integration service guarantees, policies, authentication, or retry behavior changes.