A Web Application, End to End
You've met all the pieces — DNS, CDN, load balancers, virtual machines, containers, databases, object storage, private networks, identity, encryption, monitoring, and the meter. Now it's time to put them in the same picture and trace what actually happens when someone visits a cloud-hosted web application.
This is a conceptual walk, not a tutorial. The goal is to see one complete system — every building block in its working position — so the concepts stop being a list and become a mental model of a real thing.
The analogy: think of a busy restaurant in full service. There's a host at the door who directs each customer to a table (the load balancer). The kitchen prepares every dish (the servers). The pantry holds all the ingredients (the database and storage). The whole operation runs inside one building (the private network), with a security desk at the entrance (identity and access controls). Every piece has a job; none works alone.
The Request Arrives
A user types a web address into their browser. The first thing that happens is a DNS (Domain Name System) lookup — a translation from the human-readable name (like "example.com") into a numeric address the network can route to. This was covered in the networking chapter.
Before the request even reaches the main servers, a CDN (Content Delivery Network) may intercept it. If the page's static content — images, style files, scripts — is already cached at a nearby CDN edge location, it's served immediately from there, reducing the distance the data has to travel and speeding up the response.
If the request requires a fresh response (a user's account page, a search result, a purchase), it passes through to a load balancer. The load balancer's job is to spread incoming requests across multiple application servers, so no single server becomes overwhelmed. It's the host at the restaurant door, deciding which table — which server — gets the next customer.
The Application Runs
Behind the load balancer sit the application servers — the machines (or containers, or functions) that run the actual logic of the application. When a user searches for a product, these servers process the query. When a user places an order, these servers validate the payment and update the records.
There are usually multiple copies of the application server, not just one. Under light traffic, a few copies handle everything. Under heavy load, the auto-scaling system starts additional copies. When traffic falls, they are retired. This elasticity — one of the cloud's defining traits — happens automatically, without anyone manually adding machines.
The Data Layer
The application servers read and write data in two main places. A managed database holds structured records: user accounts, orders, product listings, transactions — anything that needs to be queried, updated, and kept consistent. Databases are optimized for working with rows and relationships.
Object storage holds large, unstructured files: profile photos, product images, video uploads, generated reports, backups. Object storage is not a database — it doesn't answer queries like "find all users who signed up this week." It answers requests like "give me this specific file." The two are complementary, not interchangeable.
Around It All
All of the above — load balancer, application servers, database, object storage — lives inside a private network (a virtual private cloud or VPC). The private network means the database is not directly reachable from the public internet; only the application servers inside the same network can talk to it. This boundary is a fundamental security layer.
Identity and access controls define which services and users can talk to which other services. Encryption protects data in transit (between every piece) and at rest (in the database and storage). Monitoring watches every component, alerts on failures, and feeds logs to an observability system. And the cloud provider's meter is running the whole time, counting every request, every byte, every second of compute used.
- "A website is just one server." A typical cloud-hosted application is many coordinated pieces: DNS, CDN, load balancer, multiple app servers, a database, object storage, monitoring. One server is a simplified starting point, not the norm.
- "The database and the file storage are the same." A database stores structured records you can query and update. Object storage holds files you retrieve by name. They solve different problems; most apps use both.
- "The load balancer is the app." The load balancer only routes incoming requests to the real app servers — it runs no application logic itself. Without app servers behind it, it has nothing to route to.
- "This is too advanced for me." Every piece in this picture was introduced in an earlier chapter. This topic only places them in relation to each other — there's nothing new here, only assembly.
- Seeing the whole assembly turns a list of isolated concepts into a working mental model — the kind of picture that makes cloud conversations make sense from the outside.
- Tracing the path of a request from DNS to database gives you a vocabulary for asking precise questions: "Where does the CDN fit?", "What does the load balancer actually do?" — instead of treating the cloud as a black box.
- Understanding that the database and object storage serve different roles — and that both live inside the private network — is a recurring distinction in architecture discussions.
Knowledge Check
What is the first thing that happens when a user types a web address into their browser?
- The load balancer receives the request and routes it to an available app server in the pool
- A DNS lookup translates the human-readable address into a network address
- The database checks whether a record for that address exists
- Object storage returns the cached address from a recent lookup
What is the difference between a managed database and object storage in this architecture?
- The database is inside the private network; object storage is on the public internet
- The database runs application logic; object storage only stores static data">The database runs application logic; object storage only stores static data
- The database stores structured records for querying; object storage holds large files retrieved by name
- They are interchangeable; you pick one and use it for everything
Why does the architecture keep the database inside a private network?
- To make database queries run faster by keeping network traffic short
- So the database is only reachable by the app servers inside, not from the public internet
- Because databases in a private network are less expensive to run">Because databases in a private network are less expensive to run
- To allow the load balancer to route public requests directly to the database
You got correct