In part 4 of our System Design series, we’re exploring the building blocks of distributed systems. These are the principles that separate toy apps from production-grade platforms.
We’ll cover:
- CDN & Edge – serve static content near users
- Sharding – hash, range, geo; handling hot keys
- Replication – sync/async, leader/follower, read replicas
- Consistency Models – strong, eventual, causal
- CAP Theorem – in partition, pick A or C
1. CDN & Edge
TL;DR: Put content closer to users to cut latency.
- CDN (Content Delivery Network): Caches static assets (images, CSS, JS) at edge locations worldwide.
- Edge computing: Pushes logic (e.g., auth, personalization) closer to users.
👉 Example: Netflix streams video chunks from servers near your city, not across the ocean.
👉 Interview tie-in: “How would you reduce latency for global users?” — CDN is step 1.
2. Sharding
TL;DR: Split data across multiple nodes for scale.
- Hash-based: Even distribution, but rebalancing is tricky.
- Range-based: Easy for range queries, but hotspots form.
- Geo-sharding: Route users to nearest region.
👉 Problem: Hot keys — a celebrity account with 10M followers can overload one shard.
👉 Solution: Key-splitting, consistent hashing, or virtual shards.
👉 Interview tie-in: “How do you handle scale in a key-value store?” — talk sharding.
3. Replication
TL;DR: Keep multiple copies of data for durability & scale.
- Leader/follower (primary/replica): One leader handles writes, replicas handle reads.
- Synchronous: Safer, but higher latency.
- Asynchronous: Faster, but risk of data loss on failure.
👉 Example: MySQL read replicas to scale reads, leader for writes.
👉 Interview tie-in: “How do you scale database reads?” — use replicas.
4. Consistency Models
TL;DR: Tradeoff between user experience and performance.
- Strong consistency: Every read sees the latest write.
- Eventual consistency: Reads may lag but converge over time.
- Causal consistency: Preserves cause-effect order.
👉 Example: Banking needs strong consistency. Social feeds tolerate eventual.
👉 Interview tie-in: Expect “Would you use strong or eventual consistency here?”
5. CAP Theorem
TL;DR: In a network partition, you must choose between Consistency (C) and Availability (A).
- CP systems: Choose consistency, sacrifice availability (e.g., Zookeeper).
- AP systems: Choose availability, tolerate stale reads (e.g., DynamoDB).
👉 Interview tie-in: They love asking “Which side of CAP would you pick?” — always tie your answer back to the product requirements.
✅ Takeaways
- Use CDN/edge to cut latency for global users
- Shard for scale, but handle hot keys carefully
- Replicate for durability and read scaling
- Know when to pick strong vs eventual consistency
- CAP isn’t academic — it’s the heart of distributed tradeoffs
💡 Practice Question:
"Design a globally available chat app. How would you shard user messages, and what consistency model would you choose?"
Top comments (0)