Single Server Architecture
Every web application in history started the same way: one machine doing everything. Before microservices, before load balancers, before Kubernetes — there was a single server. And honestly? It can take you remarkably far.
The Simplest Possible Architecture
A single server architecture means one machine runs your entire stack: the web server that handles HTTP, the application code that processes logic, the database that stores data, and the file system that holds uploads and assets.
What Lives on This Server
The Four Components
- Web Server (nginx/Apache) — Handles HTTP requests, serves static files, terminates SSL, reverse-proxies to your app
- Application Code — Your actual business logic (Node.js, Django, Rails, etc.)
- Database — PostgreSQL, MySQL, MongoDB — your persistent data store
- File Storage — User uploads, generated files, logs — all on the local disk
The beauty of this setup is its simplicity. A request comes in, nginx routes it to your app, your app queries the database (via localhost — zero network latency), reads or writes files to the local disk, and returns a response. Everything communicates over local sockets or shared memory. No network hops. No distributed systems headaches.
When This Is Perfectly Fine
A single server is the right choice more often than the industry wants to admit:
- MVPs and prototypes — Ship fast, validate the idea, worry about scale later
- Low to moderate traffic — Hundreds of concurrent users? A single server won't break a sweat
- Internal tools — Company dashboards serving 50 employees don't need Kubernetes
- Side projects — Your blog doesn't need multi-region failover
A startup's first deploy: A SaaS startup launches on a $20/month DigitalOcean droplet (2 vCPUs, 4GB RAM). Running nginx + a Node.js API + PostgreSQL, it comfortably handles 500 concurrent users, serves 2 million page views per month, and responds in under 100ms. They don't need to think about scaling for their first 6 months.
The Concrete Numbers
What a Single Server Can Actually Handle
| Component | Approximate Capacity |
|---|---|
| PostgreSQL (simple queries) | ~10,000 queries/second |
| nginx (static files) | ~50,000 requests/second |
| Node.js (API responses) | ~5,000–15,000 req/sec |
| Disk I/O (SSD) | ~50,000–100,000 IOPS |
These are ballpark figures for a modern 4-core VPS with SSD storage. Your mileage varies with query complexity and payload size.
The Ceiling: What Breaks First?
Every server has limits. Understanding which resource becomes the bottleneck tells you what to fix:
| Resource | Symptom | Typical Cause |
|---|---|---|
| CPU | Slow response times, high load average | Complex computations, unoptimized queries, image processing |
| Memory | OOM kills, swapping, database crashes | Large result sets, memory leaks, too many connections |
| Disk I/O | High wait times, slow queries | Database writes, logging, file uploads without SSD |
| Network | Timeouts, dropped connections | Serving large files, API rate spikes, DDoS |
For most web apps, memory or disk I/O hits first — usually because the database grows and starts competing with the application for RAM.
Signs You're Outgrowing a Single Server
🚨 Time to Evolve When…
- Database and application are fighting for RAM (both want 80%+ of available memory)
- A database backup causes your app to slow down noticeably
- CPU is pegged at 100% during traffic spikes and requests queue up
- A single deploy requires restarting the database
- You need zero-downtime deploys but can't achieve them on one box
- Disk space for database + uploads + logs keeps running out
Interactive: Server Resource Simulator
Simulate increasing traffic and watch resource utilization on a single server. Click "Add Traffic" to increase concurrent users.
Concurrent Users: 10 | Response Time: 45ms ✓ Healthy