Performance is about speed for a single request. If your API takes 2 seconds to respond, that's a performance problem — and it would still be 2 seconds even if only one person was using it. You fix it by optimizing code, adding indexes, using caches, or reducing I/O.
Scalability is about what happens as load increases. A perfectly performant system can still be unscalable — if adding 100× more users causes it to crash or slow to a crawl, that's a scalability problem. You fix it by redesigning how the system distributes work.
The "fast alone, slow together" trap
The most common mistake is confusing the two. Consider a system that:
- Returns a query in 50ms with 1 user ✅
- Returns the same query in 8 seconds with 10,000 users ❌
That's a scalability failure, not a performance failure. The code isn't slow — the architecture can't handle concurrent demand.
Performance deep dive
Performance optimization targets the critical path of a single request:
Latency is the time from request to response. You reduce it by caching hot data in Redis, using a CDN for static assets, adding DB indexes, and avoiding N+1 query problems.
Throughput is how many requests per second your system can handle before degrading. You increase it with async I/O (Node.js, Netty), connection pooling, and batching writes.
The gold standard metric is p99 latency — the worst 1% of requests. Optimizing average latency hides tail latency spikes that real users experience.
Scalability deep dive
Scalability is about maintaining the same performance characteristics as load grows.
Vertical scaling (scale up) means giving a single machine more CPU/RAM. It's simple but has a hard ceiling and a single point of failure.
Horizontal scaling (scale out) means adding more machines behind a load balancer. It's more complex but nearly unlimited — this is how Google and AWS work.
For horizontal scaling to work, your services must be stateless. If a server holds session data in memory, requests must always go to the same server — you've lost the ability to distribute freely. The solution is to push state to an external store (Redis, a database).
Sharding applies horizontal thinking to databases — splitting data across multiple DB nodes so no single node becomes the bottleneck.
Message queues (Kafka, RabbitMQ) decouple producers from consumers, letting you absorb traffic spikes without dropping requests.
They interact — and can conflict
You can have one without the other:
| Situation | Performance | Scalability |
|---|---|---|
| Fast single request, collapses at 1k users | ✅ | ❌ |
| Slow single request, handles 1M users fine | ❌ | ✅ |
| Fast and handles millions | ✅ | ✅ |
| Slow and collapses | ❌ | ❌ |
Some optimizations actually hurt scalability — e.g., storing session state in-memory is fast but prevents horizontal scaling. This is the performance/scalability trade-off that system designers constantly navigate. Click any node above to go deeper on a specific concept.
Top comments (0)