Three system design problems anchor the modern interview canon: Design Twitter (or a news feed system), Design a URL Shortener (TinyURL / bit.ly), and Design a Rate Limiter. They are the three problems that virtually every system design prep book covers in its first chapters, that virtually every senior+ candidate sees at least once in their interview career, and that have become standard reference points whenever engineers discuss what a “good” architecture looks like at scale. This piece is the cultural-canon framing of all three: not the technical walkthroughs (those live in dedicated posts), but why these three specifically rose to canonical status and what each one teaches.
For the deep technical walkthroughs of each system, see the linked Phase 1 system design posts. This piece is about the meta-question: why these three?
Twitter / news feed: the architecture-thinking poster child
“Design Twitter” is the most-asked system design question at FAANG, and it earned that status by being the cleanest example of how scope, scale, and trade-offs interact in a real consumer system. The question forces the candidate to make decisions about feed generation (push vs pull, fanout-on-write vs fanout-on-read), storage (relational, key-value, hybrid), caching (Redis sorted sets for timelines), and the celebrity problem (when a single user has millions of followers, naive fanout-on-write fails). Each decision has a defensible answer; the question is generative because the trade-offs cascade — choosing fanout-on-write changes your storage requirements, which changes your caching strategy, which changes your read latency.
What makes the question canonical: every senior engineer has used Twitter, every senior engineer has reasoned about feeds in their own work, and the architecture problem is mature enough that there are agreed-upon “good” answers without there being a single correct answer. The interviewer can probe the candidate’s depth by digging into any of the sub-decisions; the candidate can demonstrate breadth by walking through the full architecture.
Real-world reference: Twitter’s actual architecture (now operating under various rebranding) uses a hybrid fanout strategy — fanout-on-write for normal users, pull/fanout-on-read for celebrity tweets. Facebook’s news feed uses a similar hybrid. The interview problem is essentially “rediscover the hybrid strategy from first principles”, and that journey is the actual signal.
URL shortener: the scope-first principle
“Design a URL Shortener” is the most-asked system design warmup. It is small enough to fit in 30–45 minutes, has a clean problem statement, and forces the candidate to think about the foundational architecture topics — encoding (base62), database choice, caching, redirect latency, distributed ID generation — without the cascading complexity of Twitter. It is the question that teaches scope-first reasoning: state the requirements clearly, scope down to a defensible MVP, then add complexity layer by layer.
What makes the question canonical: it is the cleanest example of how a senior engineer should approach an ambiguous problem. The first 5 minutes of the answer should be requirements clarification: how many URLs per day, what is the expected lifetime, do shortened URLs need to be customizable, what about analytics, what is the read-to-write ratio? The remaining 30 minutes should walk through the design, with each component justified by the requirements established at the start.
Real-world reference: bit.ly, TinyURL, t.co (Twitter’s URL shortener), and goo.gl (now retired) all use roughly the same architecture: a key-value store with a base62 ID and a CDN-cached redirect path. The interview problem is “re-derive this architecture”, and the journey through requirements clarification, ID generation, storage, and caching is the standard introduction to system design thinking.
Rate limiter: the API-economy classic
“Design a Rate Limiter” became canonical with the rise of the modern API economy in the 2010s. The problem requires the candidate to choose among several rate-limiting algorithms — token bucket, leaky bucket, fixed window, sliding window log, sliding window counter — each with its own trade-offs around accuracy, memory, and burst handling. The decision tree is genuinely interesting and forces the candidate to engage with the precise meaning of “rate limit” rather than treating it as obvious.
What makes the question canonical: rate limiting is the kind of problem that every senior engineer encounters in their actual work, but few have implemented from scratch. Walking through the algorithm choices, the storage requirements (Redis being the standard answer for distributed rate limiting), the burst-vs-steady-state trade-offs, and the multi-tier rate limiting (per-user, per-API-key, per-IP, global) is exactly the kind of ground that distinguishes a senior engineer from an intermediate one.
Real-world reference: every major API platform implements rate limiting. Stripe’s docs explicitly describe their approach (sliding window counter at multiple tiers). AWS API Gateway uses token bucket with burst. Cloudflare’s edge rate limiting uses anycast distributed counters. The interview problem maps directly to production systems that exist at scale.
Why these three specifically
Many system design problems exist; only these three are universally treated as canonical. Three reasons:
- Coverage. Together they cover the major sub-areas of system design: feed/timeline systems (Twitter), storage and CDN architecture (URL shortener), and rate limiting / API design (rate limiter). A candidate who has internalized all three has the foundations for a much broader set of problems.
- Length. Each fits cleanly in a 45–60 minute interview slot. Some other problems (design Google Search, design Netflix) are too big for a single round; some (design a stack with min) are too small.
- Real-world relevance. Each of the three has obvious production analogs that the candidate has likely used. The interviewer can probe “what would you actually do at scale” without the candidate needing exotic infrastructure knowledge.
The companion canon
Beyond the core three, several system design problems are often included in the broader canon:
- Design YouTube / video streaming. Storage at scale, CDN, transcoding pipeline, ABR. Senior+ tier.
- Design WhatsApp / chat system. WebSockets, message ordering, presence, encryption. Senior tier.
- Design Uber / Lyft. Geospatial indexing, real-time matching, surge pricing. Senior tier.
- Design Dropbox / Google Drive. Block storage, delta sync, conflict resolution. Senior tier.
- Design a key-value store. Consistent hashing, replication, CAP trade-offs. Often the deepest of the canonical questions.
- Design search autocomplete. Trie, prefix queries, ranking. Senior tier.
- Design a notification system. Fanout, delivery guarantees, deduplication. Senior tier.
These are all “second-tier” canonical questions — well-known, frequently-asked, but not as universally first-asked as the core three.
The Alex Xu effect
Alex Xu’s System Design Interview book (2020) and its sequel did for system design what Cracking the Coding Interview did for algorithmic coding: standardized the language and the canonical problems. The book covers exactly the canonical and second-tier problems described above, with the same conceptual framework (requirements, capacity estimation, API design, data model, high-level design, deep dives, scaling). By 2022, every prepared candidate had read the book or its summaries, and interviewers had calibrated their rubrics against it. By 2026, the canon Xu codified is the de facto standard for system design rounds across the industry.
Designing Data-Intensive Applications by Martin Kleppmann (2017) plays a similar role at the “depth” level — Xu for breadth, Kleppmann for depth on databases, replication, and consistency. Together these two books are the closest thing to a required reading list for senior+ system design preparation in 2026.
What this means for candidates
For senior+ candidates preparing for system design rounds in 2026:
- Master the core three first. Twitter, URL shortener, rate limiter. Be able to walk through each in 30 minutes without referring to notes.
- Then the second tier. YouTube, WhatsApp, Uber, Dropbox, key-value store. These extend the same patterns with more complexity.
- Read Xu and Kleppmann. Or watch equivalent video summaries. The vocabulary they use is what your interviewer is using.
- Practice ambiguous-prompt handling. System design rounds start with vague prompts; the candidate’s first move (clarifying questions) is heavily weighted.
Is the canon still alive in 2026?
Yes, very much so. System design rounds at FAANG, AI labs, fintech, and tier-2 tech all draw heavily from the canonical and second-tier problems. The questions have not been retired despite being well-known because the depth dimension means the same problem can be asked at junior, senior, and staff levels with progressively harder follow-ups. A junior candidate gets credit for stating the basic architecture; a staff candidate is expected to deep-dive into one component (consistent hashing internals, CAP trade-offs, exact rate-limiter algorithm choice) at research-grade depth.
Frequently Asked Questions
How many system design problems should I prepare?
For senior level, the core three plus 5–7 second-tier problems. For staff+ level, add depth in 2–3 specific areas (databases, distributed systems, networking) using Kleppmann or equivalent.
How long should each system design answer take?
30–45 minutes for the core three. The interviewer typically reserves the last 10 minutes for follow-up questions and deep dives. Going past 45 minutes on the high-level design is a sign of not staying organized.
Should I memorize specific architectures?
No. Memorize the conceptual framework (requirements → capacity → API → data model → high-level → deep dives → scaling) and apply it to whatever problem comes up. Memorized answers read as memorized.
Are the canonical problems still asked at staff+ level?
Yes, with much harder follow-ups. The basic Twitter architecture is junior-level; the deep dive into how to handle the celebrity problem at 100M+ followers is staff-level.
What replaced these in 2026?
Nothing has replaced them; the canon has been remarkably stable since 2018. The follow-up depth has increased, but the core problems are the same. AI / ML-heavy roles have added their own canon (build a recommendation system, build a search ranking system), but those are additions, not replacements.