AZ-305 application architecture questions are rarely asking whether a diagram looks modern. They are asking whether each component is placed behind the right boundary: scale boundary, deployment boundary, failure boundary, security boundary, data boundary, or latency boundary.
Start with the behavior of the workload. A web/API tier that handles user requests usually needs short, predictable response time and horizontal scale. A worker tier that generates documents, processes imports, or reacts to events may need a different scale profile and can often run outside the user request path. A cache or durable data store is not just another box; it decides where state lives when web instances scale out.
The Exam Decision Model
Separate application components when their constraints differ materially. Different release cadence, burst pattern, failure impact, ownership, or data residency requirement is a real architecture reason to split. A simple technical-layer split is not enough by itself.
For straightforward domains, a layered design or web-queue-worker design can be the strongest answer. Web-queue-worker separates a stateless front end from background work through a queue, which lets the front end and worker scale independently while keeping slow work away from the request path.
Microservice-style decomposition is a stronger answer only when independent deployment, independent scale, bounded-context ownership, or fault isolation is worth the extra distributed complexity. It can add latency, consistency, observability, and operations work. That tradeoff matters in AZ-305 answer choices.
Compare the Main Architecture Shapes
| Scenario signal | Better exam move |
|---|---|
| Simple domain, familiar layers, no need for independent service ownership | Keep a layered or N-tier design and avoid unnecessary distribution. |
| User request triggers slow or resource-heavy work | Use web-queue-worker so the request path and worker can scale independently. |
| Producers and multiple independent consumers react to the same business fact | Use an event-driven style, while accounting for eventual consistency and idempotency. |
| Components need separate deployment, bounded-context ownership, scale, or fault isolation | Consider microservices if the benefits outweigh latency, consistency, and operations cost. |
| Burst traffic threatens a slower downstream dependency | Use queue-based load leveling when asynchronous processing is acceptable. |
| The caller needs an immediate low-latency result | Prefer a synchronous design path instead of inserting a queue just because queues decouple. |
One major trap: stateless web tiers do not mean the application has no state. The exam expects you to move session or workflow state to a distributed cache, durable store, or workflow/state component so any instance can continue processing.
Worked Scenario
A claims-processing portal lets users upload evidence and immediately see confirmation that the file was received. Virus scanning, thumbnail generation, and downstream case enrichment can take minutes during peak hours. The current design performs those tasks inside the web request, so users see timeouts and the web tier scales up just to wait on slow work.
The strongest AZ-305 design is not to split every class into a separate service. Keep the user-facing web/API tier stateless, return a fast acknowledgement, place the slow work behind a queue or event channel, and run it in a worker or function tier that scales separately. Store session or workflow state outside local web instances, and update the durable data store when processing completes.
Change the scenario and the answer changes. If the upload decision must return a final fraud score in the same low-latency call, a queue would violate the immediate-response requirement. If three independent teams own billing, claims, and notifications with separate release schedules and bounded data ownership, microservice-style boundaries may be defensible. If the only goal is a normal three-layer business app with no different scale or ownership pressure, an N-tier design may be enough.
Compact Decision Rules
| Ask this first | Why it matters |
|---|---|
| Does this component scale at a different rate? | Different demand curves justify independent scaling boundaries. |
| Does this work need to leave the request path? | Slow or bursty work often belongs behind a queue or event channel. |
| Does the caller need an immediate result? | Minimal-latency responses usually keep the critical decision synchronous. |
| Does a component need separate deployment or ownership? | That can justify decomposition, especially with bounded-context ownership. |
| Where does state live when instances scale out? | Stateless request tiers still need distributed session, workflow, or durable state. |
| Do latency, data residency, or security constraints change placement? | These constraints can force where API, queue, cache, worker, and data boundaries live. |
Quick Recap
If the interactive lesson does not load, remember this model: split components only when a real architecture boundary changes. Use layered or N-tier designs for simple domains, web-queue-worker for slow work outside the request path, event-driven design for independent consumers of the same event, and microservices only when independent deployment, scale, ownership, or fault isolation outweigh distributed complexity.
Ready to test this under AZ-305 constraints? Take the targeted assessment and look for scenarios where latency, state, ownership, and burst handling change the right architecture boundary.