AZ-305 Application Architecture: Messaging, Events, APIs, Caching, Configuration and Deployment

Choose the messaging service by asking what kind of data is moving: a business message that someone expects to be processed (Service Bus), a notification that something happened (Event Grid), or a continuous stream of telemetry (Event Hubs). Azure Queue Storage is the low-cost option when all you need is a very large, simple work queue. Microsoft's guidance on choosing between Azure messaging services draws the same line between a message, where the producer expects the content to be acted on, and an event, which is a lightweight fact the publisher doesn't care how anyone handles.

The services are often combined in one design. A claims system whose underwriting, payments and audit services each take only the claims they deal with, and must find them waiting after a weekend offline, fits Service Bus topics with filtered subscriptions; location pings from the adjusters' mobile app in the same solution fit Event Hubs. Event Grid is a poor fit for the claims flow because it retries delivery for at most 24 hours, while Service Bus holds messages until they are settled or expire.

Two misconceptions cause most wrong answers. First, Service Bus and Queue Storage remove a message once it is processed, so neither lets a team re-read yesterday's data; only Event Hubs keeps a replayable stream. Second, Event Grid and Event Hubs subscribers each see every event that matches them; neither hands a command to exactly one of several competing workers, which is what a queue does.

Service Bus is the right broker when message handling must be reliable and controlled, and its features each solve one specific problem: sessions for ordered, exclusive handling per key; duplicate detection for retried sends; the dead-letter queue for poison messages; and transactions for atomic receive-and-forward. A queue delivers each message to one of several competing consumers. A topic with subscriptions delivers a copy to each subscription, and each subscription can carry SQL or correlation filter rules so a consumer only gets the messages it handles.

Receivers normally use peek-lock: the message is locked, processed and then completed, abandoned or dead-lettered. If the receiver crashes, the lock expires and the message is redelivered, and each redelivery counts towards the maximum delivery count. That is why redelivery alone can't keep two actions consistent: if a handler sent a confirmation before crashing, retrying the payment message doesn't unsend it. A Service Bus transaction groups the settlement of the received message with sends to other entities in the same namespace, so the outcome is all or nothing without compensation code.

Duplicate detection is configured when the queue or topic is created and compares the application-set MessageId within the chosen window. The sender must therefore reuse the same MessageId when it retries. Ordering by itself is a different need: an Event Hubs partition key also keeps one entity's events in sequence, but Event Hubs has no per-message settlement, delivery count or dead-letter queue, so it can't set a failing item aside automatically.

Pick the Service Bus tier from the features the scenario names: Basic offers queues only, Standard adds topics, sessions, transactions and duplicate detection on shared capacity, and Premium adds dedicated capacity, large messages, private endpoints, full JMS 2.0 and Geo-Replication.

Standard namespaces run on shared, multitenant resources, so latency and throughput vary with other tenants' load. No amount of tuning on shared capacity removes that noisy-neighbour effect. When a scenario asks for predictable performance that can be scaled, the answer is Premium, scaled by adding messaging units. Premium is also the destination for an on-premises JMS broker migration, since Java apps that use JMS 2.0 then change only connection settings; Event Hubs (Kafka and AMQP) and Event Grid (HTTP and MQTT) don't speak JMS.

Queue Storage versus Service Bus queues. A Service Bus queue tops out at 80 GB (on Standard only with partitioning). Queue Storage lives in a storage account and can hold a far larger backlog at lower cost, but each message is small (64 KB), ordering isn't guaranteed and there are no topics, sessions, transactions or duplicate detection. For a huge, unordered competing-consumer backlog with none of those needs, Queue Storage is the cost-effective choice.

Surviving a region failure. Service Bus Premium offers two features that are easily confused:

The two can't be combined on one namespace, and Geo-Replication doesn't support large messages. Availability zones (within one region) protect against a datacentre failure, not the loss of a whole region. Hand-built active-active designs are possible, but they push replication and duplicate handling into the application.

Use Event Grid when something should react, within seconds and without polling, to a discrete event raised by an Azure resource or by your own application. Event Grid pushes each event to the handlers whose subscriptions match it: Azure Functions, Logic Apps, webhooks, Service Bus, Event Hubs or Storage queues.

• System topics carry events that Azure services publish, such as BlobCreated from a storage account or resource changes in a subscription. Subscribing a function to a storage account's system topic starts it within seconds of each upload, with no timer, no listing of the container and no code that tracks which files are new. Monitoring feeds arrive in batches after a delay, so they suit analysis rather than starting work.
• Custom topics carry your application's own events, published over HTTPS.
• Namespace topics (in an Event Grid namespace) add pull delivery alongside push, keep events for a configurable retention period, and host the MQTT broker.

Filtering and fan-out. Each event subscription can filter by event type, by subject prefix or suffix (for example "begins with /orders/"), and by advanced filters on data fields, so each handler receives only what it needs. Every matching subscription receives its own copy, which is fan-out, not competing consumers.

Retries and dead-lettering. If a handler doesn't acknowledge an event, Event Grid retries with back-off until the subscription's maximum delivery attempts or event time-to-live is reached; the time-to-live can be at most 24 hours. Custom topics have no retention setting of their own, so an event that is still undelivered is dropped unless the subscription has dead-lettering configured to a Blob Storage container, where it can be examined and resent. Only dead-lettering keeps the undelivered event itself; monitoring merely reports that delivery failed. Because of the 24-hour limit, a consumer that may be offline for longer needs a durable buffer such as a Service Bus queue, either instead of Event Grid or as its handler.

MQTT broker. An Event Grid namespace with the MQTT broker enabled supports MQTT v3.1.1 and v5 publish/subscribe among clients on hierarchical topics, so devices and apps can subscribe to readings from many other devices, and it can route messages to a namespace topic for downstream processing. Azure IoT Hub is the choice when you need device twins, per-device management and cloud-to-device commands; it is not a general broker for devices subscribing to each other's topics. Event Hubs (AMQP and Kafka) and Service Bus (AMQP) don't accept MQTT clients.

Use Event Hubs to ingest high-volume streams, such as telemetry from tens of thousands of devices or website clickstream, that several consumers read independently and can replay. An event hub is a partitioned, append-only log: events are kept for the retention period, and each reader tracks its own position (offset) rather than deleting what it reads.

• Consumer groups are independent views of the whole stream. Give each application (say, a billing job, a live map and a machine-learning pipeline) its own consumer group so each reads at its own pace and can rewind to an earlier offset within retention. Instances of one application that share the work belong in the same consumer group, where partitions are divided among them.
• Partitions set the maximum parallelism. Within one consumer group, each partition is read by one active reader at a time, so the number of partitions caps how many instances can share the work. On the Basic and Standard tiers the partition count is fixed when the hub is created, so size it for the peak number of parallel consumers you expect; Premium and Dedicated allow adding partitions later. Capacity (throughput or processing units) and parallelism (partitions) are separate settings.
• Partition keys keep order per entity. Events with the same key (for example a device ID) always land in the same partition and are read in order. Events sent without a key are spread across partitions, so one device's readings lose their order.
• Retention is measured in days (longer on Premium and Dedicated). It is a replay buffer, not an archive.

Kafka compatibility. The Standard, Premium and Dedicated tiers expose an Apache Kafka endpoint, so producers and consumers using standard Kafka client libraries move from a self-managed cluster by changing only configuration (bootstrap server and authentication). The Basic tier has no Kafka endpoint, and Service Bus and Event Grid don't speak the Kafka protocol.

Capture. Event Hubs Capture writes the raw stream automatically to Azure Blob Storage or Azure Data Lake Storage in time- or size-based files, with no code or extra job to run. It is the least-effort way to keep every event as files for long-term audit. A function with an Event Hubs trigger or an Azure Stream Analytics job also works, but adds code or a job to build, run and pay for, which only makes sense when events need transforming.

Recommend Azure API Management when APIs need one managed front door for consumers: a gateway that applies keys, limits, authentication and transformation by policy, plus a developer portal where consumers read documentation and get their keys. Its building blocks are APIs (operations imported from OpenAPI, WSDL and other definitions), products (bundles of APIs with their own terms and limits), subscriptions (keys that identify a consumer for a product or API), policies and the developer portal.

Combining Front Door with API Management. The services complement each other: Front Door adds a global edge entry point and WAF inspection with managed rule sets (on its Premium tier), while API Management behind it keeps its APIs, products and policies unchanged. When the two are combined, lock the origin so callers can't bypass the WAF by calling the gateway hostname directly: for example, accept only requests carrying the Front Door profile's X-Azure-FDID header value (a check-header policy) from the Front Door service tag, or connect over Private Link where the tier supports it. Choosing Front Door or Application Gateway as a general load balancer is covered with network design.

Revisions and versions. These manage change to a published API:

• A revision holds a non-breaking change, such as a header fix. You can call a non-current revision explicitly to test it on the live gateway, then make it current; consumers' URL doesn't change.
• A version, grouped in a version set and addressed by path, query string or header, is for breaking changes such as renamed fields. Existing consumers stay on the old version until they choose to move.

Products control access and limits, not change; workspaces divide ownership of APIs among teams inside one instance.

Choose the API Management tier from the networking and resilience requirements first, because only some tiers support multi-region deployment, virtual network injection or a self-hosted gateway. The tiers are Consumption, the classic Developer, Basic, Standard and Premium tiers, and the v2 tiers (Basic v2, Standard v2 and Premium v2).

The Developer tier is for development and evaluation only: it has no SLA and runs a single unit. The virtual network injection tiers (Developer, Premium, Premium v2) can also reach backends inside the network, because the gateway itself sits there; outbound integration on Standard v2 and Premium v2 is the way to reach those backends without injecting the gateway.

Policies are XML statements that run in the inbound (request, before the backend), backend, outbound (response, after the backend) and on-error sections, at global, product, API or operation scope.

• Checking the caller: validate-jwt (or validate-azure-ad-token for Microsoft Entra ID) validates a token's signature, issuer and audience at the gateway and rejects requests without a valid one, with no backend change. A subscription key identifies a subscription, not an authenticated user or app.
• Authenticating the gateway to the backend: authentication-managed-identity gets a token for API Management's own identity, and client certificates authenticate the gateway too. Neither checks the caller.
• Transformation: xml-to-json and json-to-xml convert bodies; set-header, rewrite-uri and set-body reshape requests and responses. To change what consumers receive, transform in the outbound section; to change what the backend receives, transform inbound. Because policies run only at the gateway, a transformation there changes nothing for clients that reach the backend some other way.

For a new Redis cache in Azure, recommend Azure Managed Redis, Microsoft's current Redis service; Azure Cache for Redis tiers are retiring in favour of it. Microsoft has announced retirement of the Azure Cache for Redis Enterprise and Enterprise Flash tiers on 31 March 2027 and of the Basic, Standard and Premium tiers on 30 September 2028, with Azure Managed Redis as the migration target. Check the retirement FAQ on Microsoft Learn before a migration, since these schedules can move.

High availability (a replica) is the default and is what keeps a cache serving when a node fails. Active geo-replication links caches in several regions so each accepts reads and writes locally and they converge, which suits a multi-region app that must keep working if one region goes down. This differs from the passive geo-replication of Azure Cache for Redis Premium, where the secondary is read-only. A single zone-redundant cache survives a datacentre failure but not a regional outage. Redis modules are a feature of Azure Managed Redis (and of the retiring Enterprise tiers); the Basic, Standard and Premium tiers of Azure Cache for Redis never supported them. Caches linked by active geo-replication can use only the RediSearch and RedisJSON modules.

Shared session state. When several App Service or container instances serve one app behind a load balancer, put session state in Redis so every instance reads it in memory. Keeping state in each instance's own memory ties users to one instance and loses their state when it restarts, and a disk-based store is shared but adds latency to every request.

Cache-aside. The application checks the cache first; on a miss it loads the item from the data store, writes it to the cache with a time-to-live (TTL) and returns it. Items are loaded only when first requested, and the TTL bounds how stale data can get. Priming the whole data set up front is a separate pattern for small, hot data sets. Only an in-memory cache gives sub-millisecond reads; any database query, replica or not, takes milliseconds.

Keeping cache-aside fresh after writes. When stale reads after an update become unacceptable, update the data store first and then remove (invalidate) that item's key, so the next read reloads the new value while untouched items stay cached. The order matters: invalidating first opens a window in which a concurrent read caches the old value again. The TTL is a tuning knob for staleness in general, traded against cache misses and database load, not a fix for staleness caused by updates.

Caching outside the application. Not every cache needs Redis:

• Azure Front Door caches static files (images, scripts) at its edge locations when caching is enabled on the route. Azure CDN (classic) profiles are being retired, so new designs use Front Door.
• API Management caches whole responses with the cache-lookup and cache-store policies (built-in cache, or an external Redis-compatible cache). Responses that are the same for every caller and change on a predictable schedule are good candidates: set the cache duration to match and most calls never reach the backend.

Recommend Azure App Configuration to manage non-secret settings and feature flags centrally for many apps on any host, and keep secrets in Azure Key Vault, referenced from App Configuration. App Configuration stores key-values that apps on App Service, AKS, Functions, Container Apps or VMs read through its configuration providers, and feature flags that apps evaluate at runtime, including filters that target groups of users, so features turn on or off without a redeployment. App Service application settings belong to one app, Kubernetes ConfigMaps to one cluster, and Key Vault has no feature flags or labels.

• Key Vault references. App Configuration stores only the URI of a Key Vault secret. The app's configuration provider resolves the reference by calling Key Vault with the app's own identity, so each app's managed identity needs read access to the vault's secrets, and the vault's logs show which app read it. App Configuration itself never reads the secret, so the permission belongs on each app's identity. Encryption at rest protects the store's data, but a secret saved as a plain value still lives in App Configuration.
• Labels hold variants of the same key, such as one value per environment, in one store. Labels are not an access boundary: anyone who can read the store can read every label.
• Separate stores are the isolation boundary, because access (for example the App Configuration Data Reader role) is granted per store. When only production identities may read production settings, give production its own store; environments with the same readers can share a store and use labels.
• Geo-replication adds replicas of a store in other regions that apps can read from and fail over to, which is simpler than copying settings between separate regional stores by pipeline. Recovery features protect against deletion, which is a different risk from losing a region.

Dynamic refresh. Apps can reload settings while running, without a restart. For changes that span several related keys, use a sentinel key: operators update the related keys first and the sentinel last, and apps watch only the sentinel, reloading all settings when it changes. That keeps requests to the store low across many instances and stops an instance from running with half a change applied. App Configuration also publishes key-value change events to Event Grid, for workflows that should start when a setting changes.

Automate application deployments by defining every environment as infrastructure as code (Bicep or ARM templates) deployed through a pipeline, and release new versions with a strategy that stages, verifies and can roll back quickly, such as App Service deployment slots.

Sharing and protecting infrastructure as code

A template spec is an Azure resource that stores a template with versions; users with read access (the Template Spec Reader role) can deploy it but can't change it. A deployment stack manages a set of resources as a unit: its deny settings create a deny assignment that blocks write or delete actions even for Owners, except for the principals you exclude, and actionOnUnmanage decides whether resources that leave the template are detached or deleted. Azure Blueprints is deprecated; Microsoft points users to template specs and deployment stacks instead, so never recommend it for a new design.

Pipelines without stored secrets

GitHub Actions and Azure Pipelines should sign in to Azure with workload identity federation (OpenID Connect). You add a federated credential to a user-assigned managed identity or an app registration whose subject names the repository and the branch, environment or pull request that may use it. The azure/login action exchanges GitHub's short-lived OIDC token for a Microsoft Entra token, so no client secret or certificate is stored in GitHub. Moving a secret into a vault doesn't remove the stored credential, because the pipeline still needs one to reach the vault, and an identity that belongs to a running app can't be used by a pipeline runner. To require a human sign-off, protect the deploy job with a GitHub environment that has required reviewers (or an approval check on an Azure Pipelines environment), and run what-if in an earlier job so the approver sees the preview.

Release strategies on App Service

• Deployment slots (Standard tier and above) are live apps with their own hostnames. Deploy to a staging slot, let it warm up, then swap it with production: traffic switches without downtime, and swapping back is the fast rollback. Deploying a package straight to production restarts the app and rolls back only by redeploying.
• Canary releases: slot traffic routing sends a set percentage of production traffic to the staging slot while you watch errors; after the canary period, swap it in. No second app or extra service is needed. Any setup that swaps automatically after every deployment skips that observation window.
• Blue-green with separate apps behind Front Door weighted origins or Traffic Manager also works, but adds a second app and a routing service, and DNS caching slows a Traffic Manager rollback.