Design infrastructure solutions
Messaging, Events, APIs, Caching, Configuration, and Deployment
CoreCompose reliable application integrations using messages, events, API governance, caching, centralized configuration, and safe deployment patterns.
Aligned to the current AZ-305 study guide, skills measured as of April 17, 2026, verified August 25, 2026.
Why this matters
Distributed systems fail at boundaries. Architects must choose interaction semantics and rollout mechanisms that preserve reliability without creating hidden coupling.
Must Know
- Choose Service Bus, Event Grid, or Event Hubs from the required messaging or event semantics, not throughput alone.
- Place API Management at the API policy boundary, then select regional or global application delivery according to traffic scope.
- Keep cached data, non-secret configuration, and secrets in services with the appropriate consistency and trust boundaries.
- Build retries, idempotency, dead-letter handling, health gates, progressive exposure, and rollback into integration and deployment design.
Compare and Distinguish
- Service Bus provides queues, topics, transactions, sessions, and settlement for enterprise messaging; Event Grid routes discrete events; Event Hubs ingests high-volume event streams.
- API Management provides an API gateway and policy plane; Application Gateway is regional Layer 7 application delivery; Front Door is global HTTP(S) entry and routing.
- Azure Managed Redis accelerates repeated access; App Configuration centralizes non-secret settings and feature flags; Key Vault protects secrets.
Scenario examples
- Scenario: Financial commands require ordered processing per account and dead-letter handling. Think: Service Bus sessions and queue/topic semantics.
- Scenario: Subscribers react to resource-state changes. Think: Event Grid event routing.
- Scenario: A release must reach a small audience before broad promotion. Think: slots, canary, or rings with health gates and rollback.
Exam traps
- A cache cannot become the source of truth merely to improve latency.
- Event delivery does not remove the need for idempotent handlers.
- App Configuration should reference Key Vault secrets rather than store them as plain settings.
Key takeaways
- Choose interaction services from semantics, not throughput alone.
- Keep secrets, settings, and cached data in their proper trust boundaries.
- Design deployments as controlled experiments with observable rollback paths.
How it works
- Service Bus retains a message until a receiver settles it or delivery handling moves it to a dead-letter path; queues compete for work, while topic subscriptions create independent delivery paths.
- Event Hubs appends events to partitions for consumers to read and replay with independent consumer-group positions, whereas Event Grid matches discrete events to subscriptions and attempts delivery to their handlers.
- API Management receives a client request, applies configured inbound policies, forwards the request to a backend, and applies outbound policies before returning the response; deployment gates then control which backend version receives production traffic.
Objects and administrative surfaces
- Delivery guarantees require idempotency, retries, dead-letter handling, ordering scope, duplicate handling, and back-pressure.
- API design includes identity, rate limits, transformation, versioning, observability, developer onboarding, and backend isolation.
- Deployment design includes immutable artifacts, health validation, progressive exposure, rollback, and database compatibility.
When to use it
- Use Service Bus for durable enterprise messages, Event Grid for discrete notifications, and Event Hubs for retained streams.
- Place API Management in front of backends when authentication, quotas, transformation, versions, and consumer onboarding need one policy plane.
- Use cache-aside with explicit freshness, central non-secret configuration, and staged deployments with health gates and rollback.
Security and governance implications
- Authorize publishers, consumers, API callers, cache tenants, configuration readers, and secret readers at their distinct scopes.
- Keep old and new API or database contracts compatible during progressive exposure so rollback does not corrupt or strand data.
How to validate and revise the design
- For missing or repeated work, inspect broker semantics, session or partition key, settlement, retry, dead-letter path, and idempotency key.
- For a bad rollout, compare artifact identity, configuration and secret versions, health signals, traffic exposure, schema compatibility, and rollback conditions.
More detail
- Ordering is scoped rather than universal: Service Bus sessions can preserve related-message order, and Event Hubs preserves event order within a partition, so the partition or session key is an architecture decision.
- Retries and redelivery can make a handler observe the same work more than once; idempotency and poison-message handling remain necessary even when the broker advertises duplicate-detection features.
- A safe application rollout must keep API and database changes compatible with old and new versions during progressive exposure, because a traffic rollback cannot by itself reverse an incompatible data change.
Ready for the quiz?
- Does the interaction require message settlement and ordering, discrete event notification, or retained high-volume streaming?
- Which API policies, cache semantics, configuration boundary, and secret custody must remain consistent across versions?
- How will retries, duplicate delivery, poison messages, progressive rollout, and rollback preserve correctness?
Related objectives
- D4.2.S1 — Recommend a messaging architecture
- D4.2.S2 — Recommend an event-driven architecture
- D4.2.S3 — Recommend a solution for API integration
- D4.2.S4 — Recommend a caching solution for applications
- D4.2.S5 — Recommend an application configuration management solution
- D4.2.S6 — Recommend an automated deployment solution for applications