Hosting a Web Application on Cloud Servers: A Working Architecture

Most web applications do not need a sophisticated architecture. They need a small set of correct decisions, made in a sensible order, on infrastructure that is not fighting them.

Here is an architecture that works for the great majority of applications, and the order in which to build it.

The shape

Every tier below the load balancer sits on private addressing. Nothing but the load balancer accepts traffic from the internet. That single property removes an entire category of incident, as the VPC networking guide explains.

Build it in this order

1. One server, doing everything. Do not start distributed. A single adequately sized instance running the app, database and cache will serve a surprising amount of traffic and lets you learn the real bottleneck rather than guessing at it.

2. Move static assets and uploads to object storage. This is the highest-value early change. It makes the application server stateless, which makes everything afterwards easier. The storage guide covers why.

3. Put a CDN in front. Cacheable responses stop reaching your origin. Latency improves globally. Egress falls.

4. Split the database onto its own instance. When the application and database start competing for the same memory and disk, separate them. The database goes on a private address with a security group allowing only the application tier.

5. Add a load balancer and a second application instance. Now deployments can be zero-downtime and a single instance failure is survivable. This step is only possible because step two made the application stateless.

6. Add a cache tier when the database shows repeated identical queries.

Each step is triggered by a measurement, not by a schedule.

Sessions: the thing that breaks step five

Applications that store sessions in local memory or on local disk cannot be load balanced without sticky sessions, and sticky sessions turn every instance replacement into a logout event.

Move sessions to Redis, Valkey, or the database before adding a second instance. It is a small change if done deliberately and a painful one if discovered during an outage.

TLS, and getting it right

• Terminate TLS at the load balancer or CDN.
• Use automated certificate issuance and renewal. Expired certificates remain a leading cause of self-inflicted outages.
• Redirect HTTP to HTTPS, and set HSTS once you are confident.
• Encrypt between the load balancer and the application tier if the network is shared or regulated.

Caching layers, from cheapest to most work

1. Browser cache — correct Cache-Control headers on immutable, content-hashed assets. Free.
2. CDN cache — for anonymous, cacheable responses. Very cheap.
3. Application-level cache — rendered fragments or full pages in Redis.
4. Query cache — memoised expensive queries.
5. Database buffer pool — ensure the database has enough memory to hold the working set.

Work down that list in order. Most performance problems are solved by the first three.

Deployment

Whatever the mechanism, three properties matter:

• Repeatable. The same inputs produce the same result.
• Reversible. You can return to the previous version quickly.
• Zero-downtime. New instances pass health checks before old ones are removed.

Blue-green and rolling deployments both achieve this. Which you choose matters far less than having one.

Sizing and the provider

For a single application server, the constraints are usually memory and disk rather than CPU — worker processes, connection pools and the database's buffer pool. The sizing guide covers measuring this properly.

A Linode account or DigitalOcean account suits this architecture well: both offer load balancers, private networking, object storage and managed databases at predictable flat rates, which keeps the whole stack on one bill you can forecast.

Frequently asked questions

Do I need Kubernetes? For a single application with a handful of services, almost certainly not. It solves problems of scale and multi-team coordination, and introduces operational work that a small team pays for daily.

Managed database or self-hosted? Managed, unless you have a specific reason and someone who owns database operations. Backups, failover and patching are real work.

How many application instances? Two minimum for zero-downtime deployment and failure tolerance. More when measurement says so.

Where should the CDN sit? In front of everything, with cache rules that bypass it for authenticated requests.