System Design Core Building Blocks

Why this module exists

This is the toolkit that every large system is built from. The goal is to understand when and why you use each block — not just how it works.

1) Data Modeling

Model for access patterns, not elegance.

• What are the dominant queries?
• Which fields are hot?
• What must be denormalized?

Signal: you can explain the cost of each query.

2) Storage Engines & Indexes

Indexes buy read latency at the cost of write amplification.

• B‑trees: strong for random access and updates
• LSM trees: strong for write‑heavy workloads

Signal: you can justify an engine by workload.

3) Caching Strategy

Caches are for latency, not just load.

• Cache key design matters more than TTL
• Invalidation is the hard part

Signal: you can describe staleness rules.

4) Consistency & Replication

Define “fresh enough.”

• Linearizable vs eventual consistency
• Read‑your‑writes guarantees
• Conflict resolution strategy

5) Sharding & Partitioning

Sharding reduces blast radius and enables parallelism.

• Avoid hotspots with good partition keys
• Plan for rebalancing early

6) Messaging & Async

Queues smooth spikes and isolate failures.

• At‑least‑once vs exactly‑once
• Idempotency requirements

7) Search & Retrieval

Search is not OLTP.

• Indexing pipelines
• Ranking + relevance trade‑offs
• Freshness vs cost

Practice Prompts

1. Model a ride‑sharing trip entity for real‑time and analytics.
2. Design a caching strategy for product prices that update every minute.
3. Pick a partition key for a leaderboard without hotspots.