Recap
Yesterday was about the big picture — client-server architecture, scaling, latency vs. throughput, and a first look at the CAP theorem. Today I went one layer deeper: databases, and specifically, how they hold up when a system needs to scale.
This turned out to be a bigger topic than I expected. I thought "SQL vs. NoSQL" would be the whole day. It was maybe a third of it.
SQL vs. NoSQL: Less "Which Is Better," More "Which Fits"
I used to think of this as a binary choice where one option was obviously modern and the other outdated. That's the wrong frame. It's really about what shape your data takes and how you need to query it.
SQL (relational) databases — think PostgreSQL, MySQL:
- Structured data with defined relationships
- Strong consistency guarantees (ACID transactions)
- Great when your data has clear relationships and you need to enforce integrity (e.g., financial systems, orders tied to users tied to inventory)
NoSQL databases — think MongoDB, Cassandra, DynamoDB:
- Flexible or schema-less data models
- Built to scale horizontally more naturally
- Great for unstructured or fast-changing data, high write throughput, or massive scale where strict consistency can be relaxed
The real takeaway: the choice isn't about which database is "better" — it's about which trade-offs your system can tolerate. A banking system probably shouldn't sacrifice consistency for speed. A social media feed's like counter probably can.
Replication: Copies for Reliability and Speed
Replication means keeping copies of the same data on multiple machines. I looked at two common patterns:
- Leader-follower (master-replica) replication — one node handles writes, and changes propagate to follower nodes that mostly handle reads. This spreads read load and adds redundancy if the leader goes down.
- Multi-leader replication — multiple nodes can accept writes, which is more resilient but opens the door to write conflicts that need to be resolved somehow.
The concept that stuck with me most: replication isn't free. The moment you have copies of data, you have to decide how quickly those copies need to agree with each other. That's where I ran straight back into the CAP theorem from yesterday — replication is where "choose consistency or availability" actually shows up in a real design decision.
Sharding: Splitting Data Across Machines
If replication is about copying the same data across machines, sharding is about splitting different data across machines. Instead of one giant database holding everything, you partition data — often by a key like user ID or region — so no single machine has to hold or serve all of it.
A few things I noted:
- Sharding key choice matters a lot. Pick a bad key (like something unevenly distributed) and you end up with "hot shards" — some machines overloaded while others sit idle.
- Sharding solves a storage/throughput problem, but introduces new ones: queries that need data from multiple shards get more complex, and cross-shard transactions are painful.
- This is usually a "last resort" scaling technique — you shard once vertical scaling and replication aren't enough anymore.
Replication + Sharding Together
In real large-scale systems, these aren't either/or — they're often combined. You shard data across multiple database clusters, and within each shard, you replicate for redundancy and read scaling. It was helpful to picture this as a grid: shards along one axis, replicas along the other.
What Clicked Today
The biggest realization: most of these decisions come back to the same question I hit yesterday — what are you willing to give up, and when?
- Give up some consistency to get more availability
- Give up simplicity to get more scale
- Give up flexibility to get stronger guarantees
Database design isn't a checklist. It's a series of trade-off calls based on what the system actually needs to do.
Tomorrow
Next up: caching. Where caches fit in a system, cache invalidation strategies, and why "there are only two hard things in computer science: cache invalidation and naming things" is apparently a very real problem and not just a joke.
If you work with distributed databases day to day — what's a sharding or replication decision that bit you later on? I'd love to hear the war stories.
*This is part of a 30-day series on learning system design from scratch. Catch up on Day 1 if you missed it.*v
Top comments (0)