After this lesson, you will be able to: Distinguish vertical vs horizontal scaling, stateless vs stateful services, and explain the CAP theorem in plain English with real-world examples.
Scalability is the property of a system to handle more load by adding resources. This lesson covers the conceptual axes and the canonical theorem every senior engineer references.
Vertical (scale up): add CPU / RAM / disk to a single machine. Simple, has a ceiling (the biggest available machine). Horizontal (scale out): add more machines. No ceiling; requires the workload to be distributable. Most modern web systems scale horizontally; vertical is the fallback for databases and stateful systems. Cloud providers price both: vertical (m5.2xlarge → m5.8xlarge) is a config change; horizontal requires autoscaling groups + load balancers.
Stateless: a request can be handled by any server; no per-server memory of past requests. Trivially horizontal-scalable. Stateful: server keeps in-memory state (sessions, websocket connections, cached results). Harder to scale because requests must route to the right server. The pattern: push state to a shared store (Redis, Postgres) so the application layer is stateless. Sessions in a cookie / JWT; data in the DB; cache in Redis.
When a distributed system splits (a network partition between nodes), you can EITHER stay Available (keep serving requests) OR stay Consistent (every read returns the latest write). You can't have both. Consistency wins (CP): refuse to serve writes during a partition rather than serve stale data. Used by Postgres replication, etcd, ZooKeeper. Availability wins (AP): serve from the local replica, accept that reads might be stale until the partition heals. Used by DynamoDB, Cassandra, most CDNs. The 'P' is non-negotiable in real distributed systems; networks DO partition. You're choosing between C and A under partition.
Trace what changes as users grow from 1K to 1M to 100M.
1K users: one app server + one Postgres. Total cost: ~$20/month.
10K users: one app server still fine; Postgres still fine.
100K users: app server CPU saturated. Add 2-3 more behind a load balancer. Move sessions out of memory (JWT or Redis).
1M users: DB writes saturate. Add read replicas; route reads to replicas. Add Redis cache for hot reads.
10M users: DB writes still saturate. Shard by user_id, or move write-heavy tables to a separate cluster. Add CDN for static + API GETs.
100M users: now you're a real product. Likely multi-region, multi-master, dedicated services for hot paths, async write paths for non-critical writes.
Most startups die before reaching even 1M users. Don't over-engineer too early.
Treating CAP as a 2-of-3 pick when in reality you're choosing C-or-A under P. Building for 100M users before you have 1K. Over-engineering is the second-biggest startup killer (after under-engineering). Holding session state in app server memory. Every restart logs everyone out; every load balancer route is risky. Using a NoSQL database for relational data because 'it scales'. Postgres scales much further than people think. Ignoring the network. Single-region apps are far simpler than multi-region; only go multi-region when you have a reason.
Pick the one that can't be made stateless without external storage.
Sign in and purchase access to unlock this lesson.