Cloud Computing Architecture Guide

Web Entry, Edge, and Request Flow

Goal

Trace an external request into an application and make delivery, protection, routing, identity, and trust changes explicit.

The Short Version

A public application needs a public path, not a public version of every component. The path should progressively narrow reachability and increase trust. DNS helps a client find an entry point. Edge delivery and caching reduce distance and origin load. Traffic management selects a healthy destination. Protection controls reject unwanted traffic. Web or API entry applies protocol-aware routing and policy. Application and data components can remain private behind those controls.

These jobs can be combined in one service or split across several. The design question is not "How many gateways should we use?" It is "Where is each decision made, what evidence does it produce, and can traffic bypass it?"

Follow the Request

User
  |
  v
DNS -> edge delivery/cache -> traffic protection -> web or API entry
                                                   |
                         +-------------------------+------------------+
                         |                                            |
                   static content                            authenticated API
                                                                      |
                                                                      v
                                                           private application
                                                                      |
                                                                      v
                                                                 private data

DNS establishes how names resolve, but it does not authenticate a user. An edge location can terminate TLS, cache safe content, and steer traffic, but cached objects need freshness and invalidation rules. A web application firewall can identify common malicious request patterns, while rate limits protect scarce application capacity. A load balancer distributes eligible traffic; an API gateway can apply API-specific authentication, quotas, transformations, and version routing.

Do not assume every control belongs at only one layer. Coarse abuse limits near the edge can protect capacity, while tenant-aware quotas may need authenticated context at API entry. Defense in depth is deliberate overlap with clear ownership, not duplicated settings nobody can explain.

Three Kinds of Identity

A connection proves that two endpoints established a protected channel. User identity represents the person or calling client. Workload identity represents the application component calling another component. They are related but not interchangeable.

The API entry can validate a user's token and pass only required claims. The application then uses its own workload identity to reach a data store. It should not reuse a broad infrastructure secret or treat the user's network location as authorization.

Example: Global Commerce Entry

A commerce site serves versioned images and scripts from edge caches near global users. Dynamic API calls pass through request filtering, coarse abuse protection, authentication, and tenant-aware rate limits. Traffic management sends eligible calls to a healthy allowed region. The application runtime accepts traffic only from the controlled entry path, and the database accepts traffic only from authorized workloads.

If one origin fails, the team must know which content can remain cached, which journeys can be routed elsewhere, and which state-changing requests must stop rather than risk inconsistency. "Global routing enabled" is not a recovery design by itself.

Common Mistakes

  • Making every tier public because the user experience is public.

  • Allowing a second origin hostname to bypass edge protection and API policy.

  • Applying authentication, filtering, or limits at one layer without considering overload elsewhere.

  • Caching personalized or state-changing responses without an explicit safety rule.

  • Adding multi-region routing without deciding how state and failed writes behave.

If Someone Asks You

What belongs in front of a public web application?

"A controlled path that resolves names, delivers cacheable content, filters and limits traffic, selects a healthy destination, validates caller context, and routes requests to private application boundaries. The exact services vary, but each responsibility needs an owner and an observable decision point."

What You Should Remember

Public reachability should narrow into explicit, protected, and observable request paths.

Questions to Check Your Understanding

  1. Why are edge caching and API policy different responsibilities?

  2. Where does caller identity become trusted enough for an authorization decision?

  3. How can a public user experience depend on private application components?

Further Study