DEV Community

Sibasish Mohanty
Sibasish Mohanty

Posted on

Distributed Systems Without the Buzzwords

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:

  1. CDN & Edge – serve static content near users
  2. Sharding – hash, range, geo; handling hot keys
  3. Replication – sync/async, leader/follower, read replicas
  4. Consistency Models – strong, eventual, causal
  5. 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)