Web application architecture describes how the interface, application logic, data and external services work together. Start with 4 boundaries: what the browser does, what the server decides, where information is stored and who operates each part. A diagram of boxes is useful only when it explains requests, authority, failures and recovery.
Choose the architecture from the application’s actual task and operating needs. A small internal workflow and a public transactional service may require different arrangements. Neither a monolith nor a distributed system is automatically correct. The important question is whether the design makes responsibilities and change manageable.
What are the common architecture choices?
Microsoft’s web application architecture guide discusses common arrangements and the separation of responsibilities. The AWS Well-Architected Framework provides a broader way to consider operational, security and reliability concerns. These sources are guidance, not evidence that a particular design meets every requirement merely because it uses familiar labels.
| Arrangement | Useful characteristic to investigate | Trade-off to examine |
|---|---|---|
| Layered application | Separates interface, business and data concerns | Layers can still become tightly coupled |
| Modular monolith | Keeps deployment together while separating meaningful modules | Boundaries require discipline within the codebase |
| Distributed services | Separates selected capabilities across running components | Network failures and operational coordination increase |
| Static interface with backend services | Separates public assets from dynamic operations | Authentication, APIs and data authority still need design |
The table is an original comparison of design choices, not a performance ranking. “Microservices” does not prove scalability, and “monolith” does not prove poor structure. Inspect the actual boundaries, expected load and team capacity rather than choosing from a reputation.
Begin with a request path. Show what happens when a user submits a meaningful action, which component validates it and where the result is recorded. Include the response and any later notification. This makes the design testable in a way that a product-logo diagram is not.
Where should business rules and authority live?
Identify the rules that determine whether an action is permitted and what it means. A browser can help users enter information, but authoritative validation should not depend only on a control being hidden or disabled. The server-side or otherwise trusted boundary must enforce the relevant rule.
Separate authentication from authorisation. Knowing who someone is does not automatically establish which records or actions they may access. Record those decisions in terms of the actual roles and data relationships. A generic login component does not resolve the application’s permission model.
Keep data ownership explicit. If several systems can update a customer or order, define which record is authoritative and how conflicts are handled. Duplicating a field across services can be reasonable, but the design must explain how it remains meaningful.
Avoid distributing a process before its boundaries are understood. Moving poorly defined responsibilities into separate services can make the same confusion harder to diagnose. A well-structured single deployment may be easier to operate until a genuine requirement supports separation.
How should failure and repeated actions be designed?
A request can reach a server even if the browser never receives its response. Define what happens when the user retries. A repeated action should not silently create a second obligation where the intended result is one order, booking or payment request.
Identify which operations can be retried safely and how the system recognises an existing result. Keep external references where an integration needs reconciliation. These are requirements to implement and test, not guarantees supplied by choosing a particular architecture pattern.
Plan for partial failure. An order might be recorded while a notification fails. Treating both events as one unexplained success or failure can lead staff to repeat the wrong part. Define the durable business state and make any incomplete follow-up visible.
Use this original architecture review sheet:
| Boundary | Question | Evidence to inspect |
|---|---|---|
| Interface | What does the user see and submit? | Task flow with normal and error states |
| Authority | Where are permissions and business rules enforced? | Explicit rule and enforcement point |
| Data | Which record is authoritative? | Ownership and relationship definitions |
| Integration | What is exchanged with another system? | Contract, reference and failure behaviour |
| Repetition | What happens after a retry? | Demonstrated handling of duplicate requests |
| Observation | How is a failure detected and investigated? | Useful logs and an accountable responder |
| Recovery | What must be restored together? | Tested recovery plan for the relevant components |
| Change | How is a release introduced and reversed? | Reproducible deployment and rollback route |
The sheet is an original practical artefact. Use it to review an actual journey, not as a checklist that automatically approves an architecture. A missing answer should become a specific investigation or design decision.
What operational responsibilities belong in the design?
Name the owners of deployment, updates, monitoring and recovery. A technically valid design can still fail if nobody responds to an alert or understands how to restore data. Operating work is part of the architecture, not a document to add after launch.
Keep secrets out of public assets and ordinary source records. Identify how trusted components obtain the credentials they legitimately need. This guide does not prescribe a particular cloud permission change or authorise broad access; the actual system needs an appropriate controlled design.
Define backup scope from the data relationships. Restoring one database without the corresponding files or external references may not recreate a coherent service. Test the relevant recovery outcome and record the limits, rather than treating a successful backup job as complete proof.
How do you make the design maintainable?
Use names and boundaries that match the business problem. A module called “booking” is meaningful only if its responsibilities are clear. Document why important choices were made and what evidence would justify revisiting them.
Keep the design proportionate. Add a component when it solves an identified problem, not because an architecture diagram looks more sophisticated with extra boxes. The team should be able to explain the request path and the cost of operating each part.
Trace one concrete write through the boundaries
For a fictional appointment request, draw Browser → request handler → booking rule → repository → durable record. Return a reference only after the chosen transaction establishes the recorded result. Treat a later email as separate work: if delivery fails, retry that notification without creating another appointment. Specify how a repeated request finds the original outcome; a label such as “microservice” does not implement that rule.
In Microsoft’s layered example, UI calls business logic, which calls data access. Its Clean Architecture example reverses compile-time dependency towards core interfaces; infrastructure supplies the implementation. These are meaningful dependency differences, not synonyms for the number of servers. Logical layers may run in one deployment tier. Use the request trace to ask which dependency is necessary and where a fake implementation can isolate a test, then assess operational failures with the AWS framework. AWS expressly describes that review as a conversation, not an audit certificate.
See web development for related implementation work. To discuss architecture, get started with the main user journey, data sources, existing systems and operational responsibilities that need to be clear.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.