Server-Database Separation

Everything On One Box

Your first deployment is usually one server doing all the work.

The web app, the database, and the cache all share the same CPU, memory, and disk. One machine handles DNS resolution, HTTP requests, and every data operation.

Notice that the web app, database, and cache sit inside one machine boundary, so they compete for the same CPU, memory, and disk.

This is simple to deploy, cheap to run, and easy to debug.

It is also the setup that breaks first when traffic grows.

How A Request Flows

Follow one user request through the single server setup.

The browser resolves the domain through DNS, gets an IP address, then sends an HTTP request to that address.

The web app on that server handles the request and reads or writes data locally.

The response travels back. Every stage happens on one machine.

Why One Machine Runs Out

A single server is limited by single-machine capacity.

That means one pool of CPU, one pool of memory, one disk. Your web tier and your data tier fight over the same resources.

A heavy query can starve request handling. A traffic spike can starve the database.

Success is what exposes this limit.

Two Tiers Hiding Inside One

Inside that single server, two very different workloads are hiding.

The web tier is compute work: parsing requests, running application logic, building responses.

The data tier is storage work: reading, writing, and persisting data durably.

They grow at different rates and need different hardware. Yet on one box they are forced to share.

The First Scaling Move

The first major scaling step is moving the database onto its own server.

Nothing about your application logic has to change fundamentally. The web server now reaches the database over the network instead of locally.

What changes is the boundary.

Notice the database has moved outside the web server's box, so the two tiers now talk across a network link instead of sharing one machine.

Compute and storage stop competing for the same machine.

Independent Scaling

Separation buys you one thing above all: independent scaling.

If request volume climbs, add web servers without touching the database. If your dataset grows or queries slow down, give the database more memory and faster disks.

Each tier gets the hardware profile it actually needs.

On one box, every upgrade meant paying for both.

.

What The Split Costs

Separation is not free.

Data access now crosses the network, so every query carries latency it did not have before. You have a second machine to configure, secure, and monitor.

A network failure between the tiers is a new way for the system to break.

The trade is worth it because the ceiling moves. Complexity is the price of headroom.

Knowing When To Split

Do not separate on day one out of habit. Separate when the evidence says to.

Watch for the database and the web app competing: CPU pinned during queries, memory pressure, disk contention.

Ask one question. Is the bottleneck compute or storage?

If you cannot answer it on one box, that is your signal to split.

Key Takeaways

One server is a fine starting point and a poor ending point.

The web app, database, and cache all sharing one machine is simple but limited by single-machine capacity.

Separating the database is the first major scaling step. It lets you scale compute and storage independently.

Everything after this, replication and caching layers, builds on that boundary.

Moving the database to its own server allows the web tier and data tier to scale independently.

• True
• False

Answer: True

Correct. Separation gives each tier its own machine, so web capacity and database capacity can be adjusted separately. Keeping both on one server forces upgrades to support both workloads together.

Word pool: web tier; data tier. Parsing requests and building responses belong to the _____, while reading and durably storing data belong to the _____.

Answer: Word pool: web tier; data tier. Parsing requests and building responses belong to the web tier, while reading and durably storing data belong to the data tier.

The web tier performs compute-oriented request and application work. The data tier performs storage-oriented reading, writing, and durable persistence. These workloads may share one machine initially but have different resource needs.

A web application and its database share one server. Queries are causing CPU and memory pressure, while request traffic is also increasing. What is the first major scaling move described here?

• Move the database to its own server
• Add a cache while keeping everything on one server
• Replace the web application with a different framework
• Combine database queries with request parsing

Answer: Move the database to its own server

Moving the database to its own server separates compute work from storage work. The application can then reach the database over the network, allowing each tier to receive hardware suited to its workload.