16 System Design Interview Problems: Senior Roadmap (2026)

System design preparation often becomes a pile of disconnected answers: here is one diagram for a feed, another for ride-sharing, memorise both. That approach breaks when requirements change. A stronger answer decomposes the stated problem, quantifies the important assumptions, and defends trade-offs rather than reproducing a branded architecture.

Each post in this series uses one classic problem to foreground a core pattern or reference architecture, while still covering the surrounding correctness, reliability, security, and operational decisions. Later problems deliberately reuse earlier ideas. The goal is a pattern library you can adapt, not 16 fixed answers. 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
9. Frequently Asked Questions
10. Related Articles

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.

For a guided curriculum, work through the tiers in order. If you already know the foundations, use the dependency graph to jump to a weak area and review only its prerequisites.

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 case studies: decentralised ID generation, Dynamo-style coordination, collaborative editing, and GFS-style chunked storage. Read these after the first four tiers or jump directly to the model relevant to your target role.

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. One useful learning path across all five tiers. An arrow from A to B means B revisits an idea foregrounded in A; it is a study dependency, not a claim that the production systems must share an implementation. The Job Scheduler (P12) brings together counters, queues, distributed workers, and idempotency, which makes it a useful close to the core series.

The table below is a catalogue of where each pattern receives its main explanation and where related decisions also appear. “Also appears in” is thematic, not a claim that those posts use an identical implementation or occur later in the reading order.

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.

Frequently Asked Questions

What are the most common system design interview problems?

Common prompts include URL shorteners, rate limiters, notification services, caches, feeds, chat, ride-sharing, crawlers, autocomplete, video streaming, payments, schedulers, ID generators, key-value stores, collaborative editors, and file systems. Each problem exercises several reusable patterns and trade-offs, so learn how to compose them instead of memorising one architecture.

In what order should I study system design problems?

If you want a guided path, start with the URL shortener, rate limiter, notification service, and distributed cache. Then move through real-time and social systems, data-intensive systems, correctness-focused problems, and the second foundations tier. Experienced candidates can jump directly to a weak area and follow its prerequisite links.

How is this series different from a list of system design questions?

The series treats each prompt as a way to practise transferable patterns, constraints, and failure modes. Later posts reuse earlier ideas, but no design has one universal answer. The goal is to compose and defend a design for the stated workload instead of memorising diagrams.

What level is this system design series aimed at?

Senior and above - senior, staff, and principal engineers. The posts assume you already know the basics and the interview framework, and they focus on the depth interviewers expect: quantitative trade-offs, explicit consistency models, failure modes, multi-region concerns, and how an architecture evolves with scale.

Do I need to know the system design framework before reading this?

No, but the framework makes the walkthroughs easier to follow. Read the System Design Interview Guide first if you need a structure for clarifying requirements, estimating scale, defining interfaces and data, sketching components, choosing a deep dive, and discussing failure modes.

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.