Single Server Setup
Building a system that can handle millions of users is not something that happens overnight. It is a long journey of continuous improvement — one that never truly stops.
That journey begins with something deceptively simple: everything running on a single server.
The single-server stage is often overlooked, yet it is precisely here that we are forced to understand three fundamental things before introducing any new component into the system: what the actual workload looks like, where the bottlenecks are, and what metrics provide a clear, justified reason to start scaling.
What We Are Building
As a reference throughout this series, we will design a simple content platform — something along the lines of a social app or a blog. The core features include:
- User registration and login
- Creating, reading, updating, and deleting posts
- Liking and commenting on posts
- Viewing a user timeline or feed
Goals We Want to Achieve
This system is designed with several long-term targets in mind: the ability to support millions of users, high availability and reliability, low latency, horizontal scalability, and cost efficiency.
Single Server Architecture
At this stage, every component runs on the same machine. Here is an overview of the request flow.
Every request from users — whether loading a page, submitting a form, uploading a file, or fetching data — is handled by a single server, from the front-facing web layer all the way down to storage.
As a starting point, a reasonable server specification might look like this: 8 vCPUs, 16 GB of RAM, 500 GB of SSD storage, and Ubuntu 22.04 LTS. These are not fixed values — they simply represent a sensible baseline to begin with.
Metrics to Monitor
To know when a server is beginning to struggle, there are several metrics worth tracking consistently.
Requests Per Second (RPS) indicates how many requests the server can handle within a single second. Latency — particularly at the P50, P95, and P99 percentiles — reflects the response times that users actually experience. High CPU usage typically signals a compute bottleneck. High memory usage means available RAM is insufficient for the application or its cache. And high disk I/O is usually caused by expensive database queries or frequent large file uploads.
Common Bottlenecks
In a single-server architecture, there are four points most likely to become sources of failure. The CPU can be overwhelmed by too many concurrent requests or computationally intensive tasks. Memory can be exhausted when RAM is insufficient for both the application and the cache layer. The disk can become a bottleneck due to heavy database queries or large file upload operations. And the network can degrade when bandwidth consumption is excessively high or network latency is significant.
When to Start Scaling
Scaling should be driven by clear signals — not by trends. Some reliable indicators to watch for include: CPU utilization consistently above 70%, memory usage above 80%, disk I/O above 70%, degrading latency at P95 and P99, or RPS approaching the server's maximum throughput.
When one or more of these signals appear persistently, the single server has reached its limits. That is the point at which real scaling begins.
What Comes Next
Once the single-server ceiling is hit, the typical next steps involve separating the database into a primary and replica setup, adding a caching layer such as Redis, introducing a load balancer with multiple application servers, and migrating file storage to an object store like Amazon S3.
These steps will be covered in detail on Day 2.
Summary
Start simple. Measure everything. Understand your bottlenecks. Then scale — with a clear and justified reason to do so.
