From a single server to a global distributed system. Explore the strategies of Vertical Scaling, Sharding, and Replication.
Scaling a database means increasing its capacity to handle more traffic (reads/writes) and store more data. There are two primary approaches:
Upgrade the existing server with a faster CPU, more RAM, or SSDs. Simple but expensive and has a hard limit.
Add more servers. Distribute data (Sharding) or duplicate it (Replication). Complex but offers "infinite" scale.
The Golden Rule
Start Simple (Vertical)
Scale Out when needed (Horizontal)
Your startup is growing. The traffic is rising. Can you keep the database alive without going bankrupt?
Drag to simulate user surge.
Upgrade CPU/RAM. +Capacity. $$$ High Cost.
Offload reads to slave nodes. +Read Cap.
Redis layer. Drastically reduces Read Load.
Partition data. +Write Cap. +Complexity.
Also known as "Scaling Up". You keep the same single server but make it more powerful.
Simple. No code changes needed. Data consistency is trivial.
Hardware has limits (max RAM). Very expensive. Single Point of Failure.
A form of horizontal scaling where you split your data across multiple servers based on a "Shard Key" (e.g., User ID).
Near infinite write scalability. Smaller indexes mean faster queries.
Complex logic. Joins across shards are difficult/slow. Rebalancing data is hard.
Keep one Primary node for writes, and copy data to multiple Replica nodes for reads. Perfect for read-heavy apps (like Twitter/Instagram).
Since data takes time to copy, a user might write a post and not see it immediately on a refresh if they hit a Replica that hasn't updated yet. This is called "Eventual Consistency".
Imagine getting the horizontal scaling of NoSQL with the strict consistency (ACID) of SQL. These databases handle sharding and replication automatically under the hood.
Separates "Storage" from "Compute". The database automatically sleeps when idle and instantly adds CPU power when traffic spikes. You pay for what you use.