Design application architecture and integration solutions in Azure
Choose messaging, event streaming, event routing, caching, API management, infrastructure automation, and centralized configuration from workload evidence.
Suggested study time: 96 minutes • Intermediate • Complete original rewrite with a concise summary for every topic
By João Ricardo Dutra••Complete original content
1. Start with the distributed workload and its contracts
A monolith keeps calls and state inside one process. A cloud application often separates front ends, APIs, workers, functions, and data services so that each can deploy and scale independently. That freedom introduces distributed state, parallel work, asynchronous completion, partial failures, and versioned contracts.
The fictional Tailwind Traders product-demo platform must upload reviews and media, notify interested mobile clients worldwide, support rapidly changing offers, publish partner APIs, deploy repeatedly, and separate configuration from code. An AI-ready architecture can add triggered functions or intelligent back ends, but it still needs reliable communication and governance.
Distinguish commands/messages from event notifications.
Choose queues, topics, streams, and event routing from delivery requirements.
Design caching, API integration, automated deployment, and centralized configuration.
Evaluate security, resilience, scale, operations, and cost across the complete flow.
Topic summary
Map producers, consumers, contracts, state, scale, latency, failure behavior, and ownership before selecting an Azure service.
2. Messages and events express different intent
A message carries the data needed for a receiver to perform an expected action. The sender deliberately asks for work and normally cares whether it is processed. For example, an upload API can place the new file details on a queue so a worker creates thumbnails or validates video.
An event states that something happened. The publisher does not command a particular consumer and might not know whether zero, one, or many subscribers care. Events should usually contain lightweight facts and a reference to the changed object rather than the entire object.
Intent drives the model: request work with a message; announce a fact with an event.
Topic summary
Use a message when processing is expected and an event when independently owned consumers may react to a fact.
3. Delivery semantics belong in the contract
At-most-once delivery avoids redelivery but can lose work after a failure. At-least-once protects work by allowing redelivery, so consumers must be idempotent and deduplicate when business effects cannot repeat. Ordering is usually scoped to a queue, session, partition, or key—not automatically to the whole distributed system.
Define acknowledgement, retry, backoff, timeout, lock duration, expiration, and poison-message handling.
Give every operation a correlation or idempotency key and make state transitions safe to retry.
Separate transport delivery from business completion; an accepted message is not proof that the order finished.
Monitor age of oldest item, backlog, dead-letter count, throttling, processing latency, and failure rate.
Topic summary
Reliable transport still requires idempotent consumers, explicit retry policy, observability, and a recovery path for unprocessable work.
4. Azure is a simple, durable work backlog
Azure is part of an Azure account and can hold millions of messages within account capacity. Producers and workers access it through HTTP/HTTPS APIs, and messages survive temporary consumer outages. It fits decoupled asynchronous work, large backlogs, processing progress, and audit-oriented flows that do not need broker features.
The payload limit is 64 KB. Store large media in and enqueue a secure identifier plus the metadata needed to process it. Visibility timeout hides a received item temporarily; the consumer deletes it after success or lets it become visible again after failure.
emphasizes a simple durable backlog; adds enterprise broker semantics.
Topic summary
Choose for a very large, inexpensive, durable queue when advanced broker semantics are unnecessary.
5. Azure is an enterprise message broker
Azure decouples applications across organizational and network boundaries through queues and topics. It is designed for high-value business messages that need features such as duplicate detection, transactions, sessions, ordering by session, scheduled delivery, dead lettering, filtering, and push-oriented protocols.
A queue provides competing consumers: one available receiver processes each message. PeekLock supports at-least-once behavior by locking without deleting; completion removes the message. ReceiveAndDelete provides at-most-once behavior and can lose the message if processing fails after receipt.
Topic summary
Use when business work needs broker-level reliability, transactions, routing, ordering, or dead-letter operations.
6. Topics and subscriptions implement durable publish-subscribe messaging
A topic accepts one published message and copies it to matching subscriptions. Every subscription behaves like a queue with its own backlog, consumers, filters, and lifecycle. Tailwind Traders could route a “product watched” message both to a historical record subscription and to a fan-notification subscription.
Subscriptions isolate downstream ownership and allow filtered, durable fan-out.
Use a topic when every destination must receive and process its own durable copy. Use a queue when exactly one competing consumer should handle the work. Do not confuse a broker topic with an ephemeral event notification.
Topic summary
topics provide durable one-to-many messaging; each filtered subscription owns an independent copy and backlog.
7. and solve different queue requirements
Queue selection criteria.
Requirement
queue/topic
Backlog capacity
Very large, bounded by storage-account capacity.
Entity and namespace limits depend on tier; validate current quotas.
Message size
Up to 64 KB.
Larger payload support depends on tier and protocol; use claim-check for large bodies.
Delivery
Polling with visibility timeout.
Broker protocols, PeekLock or ReceiveAndDelete.
Advanced semantics
Application implements most behavior.
Transactions, sessions, duplicate detection, scheduling, dead lettering, filters.
Typical fit
Simple task backlog and processing progress.
Orders, finance, workflows, and enterprise integration.
Topic summary
Select the queue from delivery, transaction, routing, ordering, size, backlog, and operating requirements—not from the word “queue.”
8. Azure ingests ordered streams at very high volume
Azure is a managed event-streaming ingestion service for telemetry, clickstreams, device signals, logs, fraud signals, and transaction analytics. It can receive millions of events per second, expose them to multiple processors, and capture the stream to Azure for later analysis.
The stream is append-only and ordered within each partition by arrival. Consumers pull records and track offsets; reading does not delete data, so independent applications can replay the retained stream. does not provide a queue-style dead-letter path for records that a consumer cannot process.
Topic summary
Choose for a retained, partitioned series of high-volume observations that multiple analytical consumers may replay.
9. Partitions, consumer groups, and offsets define parallelism
A partition is an ordered log and a unit of parallelism. A partition key keeps related events in the same partition when local ordering matters. A consumer group creates an independent view of the stream, while each partition should normally have one active owner per consumer group.
Provision enough partitions for planned parallelism, but avoid unnecessary complexity.
Checkpoint offsets after safe processing and design for replay and duplicates.
Use separate consumer groups for independent workloads such as fraud detection, dashboards, and archival enrichment.
Treat retention as a replay window, not as permanent business storage.
Topic summary
Partition keys preserve only local order; consumer groups isolate readers, and checkpoints make replay a deliberate operational capability.
10. capacity and tiers must be measured
In Basic and Standard, one throughput unit provides up to 1 MB/s or 1,000 events/s ingress and 2 MB/s or 4,096 events/s egress, whichever limit is reached first. Standard can use auto-inflate. Premium uses isolated processing units; observed capacity depends on payloads, producers, consumers, partitions, and protocol, so architecture requires load tests rather than a fixed promise.
Current tiers differ in maximum event size, retention, partitions, networking, Capture, customer-managed keys, geo capabilities, and isolation. Premium can retain events for up to 90 days and supports dynamic partition scale-out; Dedicated supplies a single-tenant cluster. Verify current quotas and regional availability before committing.
Topic summary
Estimate events, bytes, partitions, readers, and retention, then benchmark the chosen tier and monitor throttling and lag.
11. A streaming pipeline separates ingestion, storage, and analysis
A common design sends producers to , captures raw data to or , processes the live stream with or another engine, and publishes measures to or operational stores. preserves evidence while processors evolve independently.
Separate ingestion from real-time and historical processing so each stage can scale and recover independently.
Plan downstream backpressure, checkpointing, schema evolution, late or out-of-order records, poison-event quarantine in application storage, and disaster recovery. retention does not replace a governed archive.
Topic summary
A resilient event pipeline keeps raw evidence, isolates consumers, and makes replay, schema change, and downstream failure explicit.
Azure is a fully managed publish-subscribe service for highly scalable event distribution. Azure services and custom publishers announce state changes; filters and routes them to , webhooks, , and other supported handlers without constant polling.
A Blob-created event should carry the event type, time, subject, and object URL or identifier—not the blob itself. This keeps notifications lightweight and lets each subscriber retrieve the protected object when needed.
Topic summary
Use to react to discrete state changes and connect publishers to independently owned handlers with lightweight notifications.
13. Sources, topics, subscriptions, filters, and handlers form the route
The publisher sends an event to a system, custom, domain, partner, or namespace topic. An event subscription selects matching events with type or attribute filters and identifies the handler or delivery mode. The handler validates, authorizes, and processes the notification idempotently.
Topics organize publication; subscriptions filter; handlers own the reaction.
Authenticate publishers and handlers with or supported credentials.
Validate endpoint ownership and event schema.
Configure retry, expiration, dead-letter destination where supported, and alerting.
Avoid cyclic routes and document every fan-out dependency.
Topic summary
An design is complete only when topic, schema, filter, delivery, retry, security, and handler idempotency are defined.
14. Push and pull delivery serve different consumers
In push delivery, calls a registered public destination such as a webhook or Azure Function. It removes polling and fits handlers that can expose and validate an endpoint. In pull delivery, applications read from an namespace topic at their own pace with queue-like acknowledgement semantics.
Choose pull when the consumer controls timing, cannot expose an endpoint, needs Private Link for event consumption, or might release an event for later processing. Choose push for immediate reaction when inbound connectivity is acceptable. Both models still require duplicate-safe handlers.
Topic summary
Push favors immediate callback delivery; pull favors consumer-controlled pace, private connectivity, and queue-like handling.
15. ,, and have distinct roles
Primary service distinction.
Service
Unit of communication
Consumption shape
Representative use
Azure
Discrete state-change event.
Reactive fan-out by push or pull.
React when a blob, resource, or order status changes.
Azure
Ordered series of telemetry events.
Partitioned pull stream with replay.
Ingest clickstream, sensors, logs, or game events.
Azure
High-value command or business message.
Durable queues and filtered subscriptions.
Fulfill orders or financial workflows.
Azure
Simple asynchronous task message.
Large durable polled backlog.
Process uploaded files or background jobs.
A complete application can use all four services for different communication contracts.
Topic summary
Use the services side by side: commands for required work, streams for observations, and routed events for reactions.
16. Cache only data whose staleness and loss are understood
Caching copies frequently read data into faster storage near the application. It is most effective when the source is relatively static, heavily contended, or distant enough that network latency dominates. It can reduce response time, database load, and the number of application servers.
The design must state source of truth, acceptable staleness, expiration, eviction, invalidation, warm-up, capacity, serialization, stampede control, and behavior when the cache is unavailable. A cache should not silently become the only durable copy of business data.
Topic summary
Cache design begins with freshness, invalidation, failure, and source-of-truth rules—not merely a desire for lower latency.
17. is the current managed Redis service
is a fully managed, Redis-compatible in-memory data service built on Redis Enterprise. Applications inside or outside Azure can use it as a distributed data or content cache, session store, coordination store, or message broker, and combine it with ,, or other back ends.
performance tiers.
Tier
Resource profile
Fit
Memory Optimized
High memory-to-vCPU ratio.
Memory-heavy workloads with moderate throughput.
Balanced
Balanced memory and compute.
General-purpose starting point.
Compute Optimized
High vCPU-to-memory ratio.
Throughput-intensive and latency-sensitive workloads.
Flash Optimized
RAM plus lower-cost NVMe flash.
Very large datasets that accept a performance trade-off.
Topic summary
Select tier from memory, throughput, latency, availability, persistence, and data-size evidence.
18. Plan migration away from
is retiring. In Azure public cloud, new Basic, Standard, and Premium caches are blocked for new customers from April 1, 2026 and for existing customers from October 1, 2026; remaining instances are disabled starting October 1, 2028. Enterprise schedules differ and transition earlier. New designs should use , and existing designs need an assessed migration plan.
Do not assume a one-for-one SKU match. Measure peak used memory, throughput, connections, latency, modules, persistence, clustering, networking, authentication, geo-replication, and client compatibility. Test failover and rollback before changing the production endpoint.
Topic summary
Treat Redis migration as an architecture and compatibility project, with measured sizing and tested cutover—not as a name change.
19. Reuse proven cache patterns deliberately
Common Redis-backed patterns.
Pattern
Purpose
Critical design point
Data cache
Reduce repeated database reads.
Cache-aside, TTL, eviction, invalidation, and stampede control.
Content cache
Serve headers, banners, templates, or rendered fragments quickly.
Version content and invalidate on publication.
Session store
Keep shopping-cart or user-session state outside web instances.
Protect identifiers, choose TTL, and plan regional continuity.
Job/message queue
Defer long operations.
Use only when Redis delivery semantics meet the business requirement.
Distributed transaction
Execute a batch of Redis commands atomically.
Atomicity applies inside Redis, not across unrelated systems.
Topic summary
A named pattern clarifies cache ownership and failure behavior; it does not remove the need to test service semantics.
20. Cache-aside keeps the source authoritative
With cache-aside, the application reads the cache first. On a miss it reads the authoritative store, returns the value, and populates the cache. A write updates the source and then invalidates or refreshes the cached value. TTL bounds staleness, while jitter, request coalescing, and locks can reduce synchronized cache misses.
The database remains authoritative; the cache accelerates reads and can be rebuilt.
Secure Redis through private networking where appropriate, TLS, least privilege, secretless identity when supported, rotation, monitoring, and resource limits. Decide whether the application fails open to the database, degrades features, or rejects work during cache failure.
Topic summary
Cache-aside is resilient when the cache is disposable, misses are controlled, and the source can absorb defined fallback traffic.
21. API integration needs a governed front door
Publishing APIs can extend reach and revenue, but every interface introduces onboarding, security, versioning, documentation, analytics, quota, and support work. Tailwind Traders has APIs for mobile and web clients, vehicle IoT devices, vendors, internal teams, and analysts, while back ends remain distributed across servers and environments.
Central management becomes valuable as API count, change rate, consumer diversity, and policy burden grow. A tiny static API inventory may not justify the platform cost and operating model.
Topic summary
Quantify APIs, consumers, change frequency, exposure, policies, and administrative load before recommending an API management platform.
22. Azure separates gateway and management responsibilities
Azure publishes, secures, maintains, and analyzes APIs through a managed platform. Its gateway terminates client traffic, applies policies, and forwards calls; the management plane controls configuration; the developer portal supports discovery and onboarding. The service does not host the business API—the back end remains where it was deployed.
creates a governed facade without moving the back-end business logic.
Topic summary
APIM decouples the public contract and cross-cutting policies from distributed back ends while leaving business logic in place.
23. Policies standardize security and traffic behavior
Authenticate and authorize with , JWT validation, certificates, subscriptions, or other supported mechanisms.
Import and publish consistent specifications, base URLs, products, revisions, and versions.
Collect common telemetry, correlate requests, audit administrative changes, and protect secrets with managed identity and Azure .
Gateway policies are not a substitute for domain authorization, a web application firewall, or secure back-end implementation. Define which layer owns every control and prevent confidential data from leaking into logs or traces.
Topic summary
Use APIM for consistent cross-cutting enforcement while keeping business authorization and data validation inside the owning service.
24. Select an topology and tier from requirements
Classic Developer, Basic, Standard, and Premium tiers continue to serve established scenarios. Basic v2, Standard v2, and Premium v2 provision and scale faster; Standard v2 and Premium v2 add options for isolated back ends, and Premium v2 supports enterprise scale and full virtual-network isolation. Consumption suits variable serverless traffic. Workspaces delegate API ownership under centralized governance, and a self-hosted gateway can place the data plane near hybrid or multicloud back ends.
Features, limits, regions, networking, workspaces, availability zones, multi-region support, SLA, and cost differ by tier and evolve. Validate the current feature matrix; there is no generic automated in-place migration from a classic or Consumption instance to a v2 instance.
Topic summary
Tier and gateway topology follow SLA, throughput, isolation, regional, delegation, hybrid, feature, and cost requirements.
25. Infrastructure as code makes deployment repeatable
Infrastructure as code stores desired infrastructure and configuration in versioned files. Review, testing, approvals, and pipelines can then govern application and platform changes together. Declarative deployment describes the target state, allowing the engine to calculate dependencies and converge resources repeatedly.
A production design separates environments and scopes, protects secrets, pins module versions, validates policies, previews changes, records deployment evidence, and defines rollback or roll-forward. Repetition alone is not safety if a template contains destructive intent.
Topic summary
IaC turns infrastructure into a reviewable release artifact, but safe delivery still needs validation, approvals, evidence, and recovery.
26. provide the native declarative deployment model
templates describe Azure resources in JSON. Deployments are idempotent, validate before provisioning, create independent resources in parallel, and can compose smaller linked or nested components. What-if in Azure CLI or PowerShell previews expected creates, changes, and deletions.
Templates integrate with , GitHub Actions, and other CI/CD tools. Deployment scripts can execute Bash or PowerShell when a declarative resource is not enough, but scripts should remain exceptional, repeatable, secured, and observable.
Topic summary
are Azure-native, declarative, composable, previewable, and pipeline-friendly; imperative scripts should be controlled exceptions.
27. Bicep is the preferred authoring experience for ARM deployments
Bicep is a domain-specific language for declarative Azure deployment. It compiles to ARM JSON while offering concise syntax, type checking, modules, tooling, and day-one access to Resource Manager resource types. Azure stores deployment state, so no separate state file is required.
The Bicep CLI can decompile an existing JSON template, but generated code needs human review and refactoring. Use modules, linting, what-if, deployment stacks or appropriate lifecycle controls, and a CI/CD identity with least privilege.
Bicep improves authoring; Resource Manager remains the deployment engine.
Topic summary
Use Bicep for maintainable Azure-native IaC, then validate the compiled deployment and permissions through a governed pipeline.
28. Azure covers repeatable operational processes
Azure provides cloud-based process automation across Azure and non-Azure environments. PowerShell and Python runbooks, schedules, webhooks, credentials or managed identities, and Hybrid Runbook Workers can automate frequent, time-consuming, or error-prone management tasks.
Change Tracking and Inventory uses Agent-based collection to report changes to software, services or daemons, registry, and files. Azure State Configuration is retiring on September 30, 2027; new designs should use Azure Machine Configuration through . Design runbooks for idempotency, concurrency, logging, retries, secure assets, and least privilege.
Topic summary
Use for governed operational runbooks, while planning current agents and replacements for retiring configuration features.
29. owns current patch management
The former Azure Update Management solution retired on August 31, 2024. is the current service for assessing and scheduling operating-system updates, defining maintenance windows, and orchestrating patches for Azure VMs and -enabled Windows and Linux servers.
Patch design includes classification, cadence, maintenance configuration, reboot behavior, pre/post tasks, exclusions, health validation, phased rollout, compliance reporting, rollback constraints, and application-aware availability. Do not recommend Bicep merely because a requirement says “updates”; Bicep deploys desired resources, while Update Manager orchestrates OS patching.
Topic summary
Separate infrastructure deployment from operating-system patch operations; use for current scheduled patching.
30. Azure decouples settings from releases
Azure centrally manages application key-values and feature flags. It offers framework integrations, labels, comparison of configuration sets, immutable point-in-time snapshots for rollback and audit, and geo-replicas that synchronize changes with eventual consistency.
Feature flags can expose behavior without redeploying code, but they need owners, rollout rules, expiry dates, telemetry, and cleanup. Configuration refresh must define polling or push strategy, cache duration, failover among replicas, and behavior when the store is unavailable.
Topic summary
Central configuration accelerates controlled change only when flags, snapshots, refresh, ownership, resilience, and cleanup are governed.
31. Keep settings, identities, and secrets in their proper services
Applications should authenticate with Microsoft Entra managed identities and receive only the data-plane roles they need. Use private endpoints and network controls when required, encrypt traffic, monitor access, and protect the store with soft delete and purge protection appropriate to the environment.
stores nonsecret settings and can reference secrets held in Azure . The application identity obtains the secret from , avoiding credentials inside code or ordinary configuration. Development can use ,, and Azure CLI with developer identity; production should use workload identities and separately governed stores, labels, or snapshots.
Separate environments and let managed identities retrieve configuration and referenced secrets.
Topic summary
Use for settings, for secrets, and managed identities for access; isolate and govern development and production.
32. Assessment, decision record, and next study steps
Apply the architecture to the rewards-game requirements.
Requirement
Best answer
Reason
Group purchase details as one reliable game transaction.
Azure queue
Enterprise broker with transactional and reliable message processing.
Install scheduled updates in a maintenance window.
Current patch assessment and orchestration service.
Receive millions of low-latency game events per second and save the stream to Blob .
Azure
High-throughput stream ingestion with Capture or downstream archival.
For every design, record the producer, consumer, intent, contract, delivery model, scale unit, partition or ordering key, retry and dead-letter behavior, identity, network path, encryption, observability, cost, regional design, deployment mechanism, configuration ownership, and recovery test. One application can combine for orders, for telemetry, for state-change reactions, Managed Redis for hot reads, APIM for governed access, Bicep for deployment, for runbooks, Update Manager for patches, and for runtime settings.
Practice with comparison prompts
Explain message-oriented and event-driven architecture with two suitable real-world examples for each.
Compare , queues, and topics by delivery, routing, size, transactions, and cost.
Compare and , including stream replay, push/pull delivery, ordering, and failure handling.
Review the official service limits and regional capabilities again before implementing the recommendation.
A defensible AZ-305 answer ties each service to a specific communication or operating requirement and documents how the complete system fails, recovers, scales, and changes.
