System Design Interview Problems: A Senior's Roadmap 2026

Most system design preparation is a pile of disconnected answers: here is how to design Twitter, here is how to design Uber, memorise both. It works until the interviewer asks something off the list - and then there is nothing to fall back on. Senior interviews are not testing whether you have seen a problem before; they are testing whether you can decompose an unfamiliar one into patterns you understand and defend the trade-offs.

This series takes the opposite approach. Each post solves one classic problem built around one core pattern or reference architecture. Later problems deliberately reuse the patterns from earlier ones, so by the end you are not carrying twelve answers - you are carrying a pattern library you can compose against anything. This page is the map.

Table of Contents

1. How to Use This Series
2. Tier 1 - Foundations
3. Tier 2 - Real-Time and Social
4. Tier 3 - Data-Intensive Systems
5. Tier 4 - Correctness and Coordination
6. Tier 5 - Foundations II
7. The Pattern Library
8. Start Here

How to Use This Series

The series is aimed at senior, staff, and principal candidates. It assumes you already know what a load balancer is and how to run a system design conversation - so the posts spend their time on the depth that actually separates a senior answer: quantitative trade-offs, explicit consistency models, failure modes, multi-region concerns, and how each architecture evolves from launch to massive scale.

Every post applies the same method rather than re-teaching it. If you have not internalised that method yet, read the System Design Interview Guide: The 6-Step Framework first - clarify requirements, estimate scale, define the API and data model, sketch the high-level design, deep-dive the core component, then address bottlenecks.

Work through the tiers in order. The foundation patterns are not optional warm-ups; they are the building blocks the later problems assume you already have.

Tier 1 - Foundations

The patterns introduced here - caching, shared counters, queues, consistent hashing - reappear in nearly every other problem in the series. Do these first.

Tier 2 - Real-Time and Social

Interactive systems where data must reach many users quickly. These build on caching and queues from Tier 1.

Tier 3 - Data-Intensive Systems

Systems whose difficulty is the volume and movement of data - crawling, indexing, and streaming.

Tier 4 - Correctness and Coordination

The hardest tier: systems where being approximately right is not good enough.

Tier 5 - Foundations II

A second wave of foundational systems whose patterns - decentralised ID generation, tunable quorum, CRDTs, and chunked replication - did not naturally fit into the first four tiers but underpin much of modern distributed practice. Read these once the Tier 1-4 patterns are familiar.

The Pattern Library

This is the real takeaway. By the end of the series you hold a set of transferable patterns, each introduced once and reused many times. When an interviewer hands you a problem you have never seen, you reach into this library rather than your memory.

The graph below shows how the parts depend on one another. An arrow from one part to another means the later part builds on a pattern first taught in the earlier one - so the arrows also double as a recommended reading order. Notice that the foundations fan out widely, the Job Scheduler sits where four separate threads converge, and Tier 5 reuses the queues and consistent hashing from Tier 1, with the Unique ID Generator becoming a foundation in its own right.

flowchart LR
    subgraph T1["Tier 1 - Foundations"]
        P1[P1 - URL Shortener]
        P2[P2 - Rate Limiter]
        P3[P3 - Notification Service]
        P4[P4 - Distributed Cache]
    end
    subgraph T2["Tier 2 - Real-Time and Social"]
        P5[P5 - News Feed]
        P6[P6 - Chat System]
        P7[P7 - Ride-Sharing]
    end
    subgraph T3["Tier 3 - Data-Intensive"]
        P8[P8 - Web Crawler]
        P9[P9 - Autocomplete]
        P10[P10 - Video Streaming]
    end
    subgraph T4["Tier 4 - Correctness"]
        P11[P11 - Payment System]
        P12[P12 - Job Scheduler]
    end
    subgraph T5["Tier 5 - Foundations II"]
        P13[P13 - Unique ID Generator]
        P14[P14 - Key-Value Store]
        P15[P15 - Collaborative Editor]
        P16[P16 - Distributed File System]
    end
    P1 --> P4
    P1 --> P9
    P1 --> P10
    P2 --> P12
    P3 --> P8
    P3 --> P11
    P3 --> P12
    P3 --> P15
    P4 --> P5
    P4 --> P7
    P4 --> P14
    P5 --> P6
    P6 --> P7
    P8 --> P12
    P11 --> P12
    P12 --> P14
    P13 --> P15
    P13 --> P16

Figure 1. The pattern-dependency graph across all five tiers. An arrow from A to B means B reuses a pattern first introduced in A, so the graph doubles as a recommended reading order. The Tier 1 foundations fan out widely into later tiers, and the Job Scheduler (P12) is the convergence point where four separate threads (counters from P2, queues from P3, producer-consumer from P8, idempotency from P11) come together - which is why P12 makes a fitting close to the core series.

The table below is the same information as a catalogue - each pattern, where it is introduced, and the later problems that reuse it.

Start Here

If you are new to the series, begin with Part 1 - Design a URL Shortener. It looks like the simplest problem on the list and is exactly where the foundational patterns - read-heavy caching and keeping coordination off the critical path - are introduced.

Already comfortable with caching? Jump to Part 2 - Design a Rate Limiter for atomic distributed counters and the fail-open versus fail-closed decision.

All 16 parts of the series are now published - the original Tier 1-4 core (Parts 1-12) and the Tier 5 expansion (Parts 13-16). Bookmark this page - it is the index for the whole series, and the pattern library below is where each post fits in.

Related Articles

• System Design Interview Guide: The 6-Step Framework - the method every post in this series applies.
• Design a URL Shortener - Part 1: caching and offline ID generation.
• Design a Rate Limiter - Part 2: atomic distributed counters.