Web Application Request-Path Mental Model

Goal

Part I introduced patterns as responsibilities, flows, boundaries, and operating feedback. A web application is the first familiar place to apply that language.

A web application pattern is not just a hosting choice. It is the operated path from user intent to application response, with protection, runtime responsibility, data access, observability, cost, and ownership wrapped around it.

The durable idea is:

A web application pattern is the operated path from user intent to application response.

The Short Version

A web request path starts when a user, browser, mobile app, partner, or another system asks the application to do something now. The application may show a product page, submit a cart, upload a document, return account details, or confirm an order.

That path usually includes:

• public entry;

• routing and protection;

• web or API runtime;

• identity and authorization checks;

• data or API dependencies;

• response behavior;

• logs, metrics, traces, alerts, and cost signals.

The request path is not the whole business process. It is the part that must happen while the caller is waiting. A strong web architecture keeps that distinction visible.

The Basic Path

Start with the simplest useful picture:

User
  -> Public entry
  -> Routing and protection
  -> Web runtime
  -> Data or API dependency
  -> Response

This diagram does not say which provider service to use. That is intentional. Before naming a CDN, load balancer, app platform, container service, database, cache, or monitoring tool, the team should understand which responsibility each layer carries.

The path should expose practical questions:

This is the first web pattern habit: draw the caller's wait time.

What Belongs on the Request Path

The request path should include only work that must happen before the caller receives a meaningful response.

For a product page, the path may need product details, price, availability, personalization, and content assets. For checkout, the path may need cart validation, customer identity, payment authorization, order creation, and confirmation. For a document upload, the path may need authentication, file validation, storage, and a clear upload result.

Different actions have different request paths. Do not assume every user action should call the same dependencies or wait for the same business process.

Good request-path design asks:

• Which dependencies are required for this response?

• Which dependencies can fail gracefully?

• Which steps can be retried safely?

• Which work can continue through integration flows after the response?

• Which signals show the user experience is healthy?

This is how web architecture connects to Part I's pattern language. The web request is the flow. Public entry, runtime, and data access are boundaries. Latency, availability, security, and cost are trade-offs. Observability and ownership make the path operable.

What Should Stay Off the Request Path

A web request often triggers other work. That does not mean all of that work belongs in the caller's wait time.

For example, after a customer places an order, the platform may need to notify the customer, update recommendations, trigger fulfillment, feed analytics, update loyalty points, and inform finance systems. Some of that work may be important, but it may not need to block the response.

If everything stays synchronous, the user experience becomes fragile. A slow notification provider, overloaded analytics pipeline, or delayed back-office system can make checkout fail even when the order itself is valid.

The pattern decision is not "never call downstream systems." The decision is more precise:

Keep only response-critical work on the request path. Move non-critical or durable follow-up work into integration flows with ownership and recovery.

Example: Commerce Storefront

Consider a commerce storefront with three common requests.

This table is not a final design. It is a request-path model. It helps the team discuss which work needs immediate correctness and which work needs durable follow-up.

Latency, Failure, Security, and Ownership

The request path is where several architecture concerns meet.

Latency matters because the caller is waiting. Every dependency on the path adds time and another possible delay.

Failure matters because each dependency can be slow, unavailable, inconsistent, or overloaded. The path should define timeouts, fallback, retries, and user-facing behavior.

Security matters because a public request crosses trust boundaries. The design should show where TLS, identity, authorization, WAF policy, secrets, private access, and audit logging belong.

Ownership matters because someone must respond when the path is unhealthy. Public entry, runtime, database, cache, identity, and downstream APIs may have different owners. The architecture should make that visible before an incident.

Common Mistakes

• Treating the hosting service as the whole architecture.

• Hiding data dependencies behind a single application box.

• Putting every downstream business process on the customer request path.

• Drawing static assets, dynamic pages, APIs, and background work as if they all have the same path.

• Ignoring ownership and observability until after deployment.

If Someone Asks You

What is the first thing to draw for a web application architecture?

A good answer is:

Draw the request path. Show how the caller reaches the public entry point, how traffic is routed and protected, where the web runtime runs, which dependencies must respond, and what the caller receives. After that, add identity, data access, observability, deployment, scaling, cost, and provider implementation choices.

What You Should Remember

Start with the request path, then choose the implementation.

Questions to Check Your Understanding

1. Why is the request path the starting point for web application architecture?

2. What work should usually stay outside the immediate user request?

3. Which operating concerns should appear in the first web pattern diagram?

4. How can the same web pattern support different provider implementations?