How to use this path
Core concepts are technology-agnostic building blocks — caching, sharding, consistency — that show up in nearly every design. You need the vocabulary and a default choice under time pressure; you reach for the full article when a follow-up goes deep.
Foundations roadmap
Follow this order in the sidebar. Each step answers one question before the next layer makes sense.
- Numbers to know — Latency, throughput, and scale triggers. Do the math before you shard or cache.
- Networking essentials — How services talk: HTTP/TCP default, when SSE/WebSockets/gRPC earn a box.
- API design — REST defaults, pagination, auth — sketch 4–5 endpoints and move on.
- Data modeling — Relational by default; NoSQL when access patterns drive partition keys.
- Database indexing — B-tree for exact/range; external search when the DB isn't enough.
- Proximity search — Why lat/lng B-trees fail; spatial trees vs geohash/S2/H3 for nearby queries.
- Scalability — Vertical vs horizontal, load balancers, read replicas, stateless app tier.
- Sharding — Split when one DB can't keep up; shard key is the whole design.
- Consistent hashing — Remap ~1/N keys when nodes join or leave, not ~100%.
- CAP theorem — During a partition: consistency vs availability.
- Consistency models — Strong vs eventual — pick per data type, not globally.
- Specialized data structures — Optional depth: Bloom filter, Count-Min Sketch, HyperLogLog, quantile buckets when exact structures won't fit.
Quick reference — defaults at a glance
| Topic | Interview default | Open the full article when… |
|---|---|---|
| Networking | HTTP over TCP | Real-time, internal RPC, or load-balancer layer choice |
| APIs | REST, cursor pagination for feeds | GraphQL, versioning, or idempotency deep dive |
| Data model | Postgres, normalized first | Partition keys, denormalization, or multi-tenant isolation |
| Indexing | B-tree on query fields | Composite/covering indexes, LSM, geospatial |
| Caching | Cache-aside + TTL (Redis) | Stampede, invalidation strategy, CDN vs app cache |
| Sharding | Hash by user_id after math proves need | Hot spots, cross-shard queries, resharding |
| CAP / consistency | Eventual unless money or inventory | Linearizability, quorum reads, hybrid per entity |
After foundations — technologies
Concepts tell you why a layer exists. Technologies give you one name per layer you can defend under pressure.
- Key technologies — map the toolbox (database, cache, queue, blob, search).
- Pick depth in the order that matches most designs: databases → caching → async/events → batch/stream processing → search → edge → infrastructure.
- Apply everything in Common patterns and Question breakdowns.
Cost and performance levers
How to use this roadmap
Suggested reading order (busy week)
Day 1–2: Numbers, networking, API design. Day 3–4: Indexing, scalability, caching. Day 5–6: CAP, consistency, sharding. Day 7: One practice question end-to-end. Skip specialized structures until after your first mock.
- Transfer skill: every deep dive should end with "interview default in one sentence."
- Spaced repetition: redo Numbers and CAP the morning of interviews.
- Weak-area rule: if you can't explain it to a rubber duck in 2 minutes, open the deep dive.
Failure modes to mention
Call out at least one dependency failure (DB down, cache stampede, queue lag, region outage) and your mitigation (timeouts, retries with jitter, degraded mode, circuit breaker).
Interview Q&A by level
Practice saying these out loud for foundations roadmap. Interviewers grade clarity and judgment more than buzzwords.
Match depth to the bar: define → trade off → operate. Don't dump principal answers in an entry-level screen.