The Question Library
System Design Interview Questions
There aren't 100 different system design questions. There are roughly 10 patterns dressed up in different costumes. Once you know the patterns, the question space stops feeling infinite.
01Why Pattern Recognition Is the Senior Signal
Open any list of system design questions and you'll see the same titles repeated: design Twitter, design Uber, design WhatsApp, design Netflix, design Instagram, design Slack, design Dropbox, design Google Docs, design YouTube, design TikTok, design Spotify, design Airbnb. The list runs to dozens. Most candidates try to memorize each one as a separate problem and run out of time before they've learned even half.
This is the wrong mental model. Twitter and Instagram and Threads aren't three different problems; they're three variants of one pattern (a social feed). Uber and Lyft and DoorDash aren't three problems; they're variants of geospatial dispatch. Dropbox and Google Drive and iCloud are variants of distributed storage. The question space looks infinite from the outside but compresses to roughly ten patterns once you see the structure.
Pattern recognition is the senior signal in interviews for the same reason. Candidates who name the pattern in the first 60 seconds use it to scaffold the rest of the conversation. They know which concepts are going to dominate the discussion (caching for feeds, geohashing for ride-hailing, CRDTs for collaborative editing) and they spend interview time on those rather than rediscovering the structure from scratch.
This hub gives you the ten patterns. Each one names the variants you might be asked, the concepts that dominate, and the decisions that distinguish strong answers from weak ones. Once you've internalized the patterns, every new question becomes "which pattern is this, and what's specific about this variant?" That question is much easier to answer than "design X."
The Senior Move
Within the first minute of the interview, name the pattern out loud. "This sounds like a social feed pattern. The dominant decisions are going to be around feed materialization (push vs pull), caching strategy, and how we handle celebrity accounts." That sentence does three things: signals you've seen this kind of problem before, sets up the rest of the conversation, and gives the interviewer a roadmap of what you'll cover. The weak version is starting to draw boxes without ever naming what kind of system this is.
02The Ten Patterns
The patterns below cover roughly 95% of what gets asked in system design interviews at FAANG-level companies in 2026. The remaining 5% are either company-specific (Netflix-specific video questions, Stripe-specific payment questions) or genuinely novel, but those are rare and usually flagged in advance.
Each pattern card below names the canonical variants, what makes the pattern its own thing, and the concepts that dominate. Question walkthroughs for each pattern will be added over time; the pattern recognition itself is the foundation.
Pattern 01
Social Feed
Twitter / X · Instagram · Threads · LinkedIn · Mastodon
Users follow other users. Each user sees a feed of posts from accounts they follow. The defining question is how the feed gets assembled: at write time (push, fan-out) or at read time (pull, fan-in), or some hybrid. Celebrity accounts (high follower count) break naive push; this is the canonical problem.
Dominant conceptsCaching (timeline materialization), sharding (by user), message queues (fan-out), database selection (timeline storage), rate limiting (post creation).Pattern 02
Chat / Messaging
WhatsApp · Slack · Discord · Signal · iMessage
Users send messages to other users or groups. Messages must be delivered reliably, often in real time, with ordering guarantees and presence indicators. Group chats and message history complicate the design. End-to-end encryption is a common depth probe.
Dominant conceptsMessage queues (delivery), database selection (message storage), replication (cross-region), websocket-style connections, observability (delivery success metrics).Pattern 03
Geospatial Dispatch
Uber · Lyft · DoorDash · Instacart · Yelp nearby
Match a user at a location to nearby providers (drivers, restaurants, listings). Real-time location updates from many devices, fast nearest-neighbor queries by geography, dispatch logic that balances speed, cost, and fairness. Geohashing or quadtrees are the standard data structures.
Dominant conceptsSharding (by geography), database selection (geospatial), caching (location), message queues (location updates), rate limiting (per-driver pings).Pattern 04
Video Streaming
YouTube · Netflix · Twitch · TikTok · Vimeo
Upload, transcode, distribute, and play video at scale. Adaptive bitrate streaming, CDN topology, transcoding pipelines, view counting and recommendations. Live streaming (Twitch) adds real-time constraints; on-demand (Netflix) prioritizes catalog scale and cost.
Dominant conceptsCaching (CDN), message queues (transcoding pipeline), database selection (metadata + catalog), observability (playback quality), load balancing (regional).Pattern 05
Search
Google-like search · e-commerce search · autocomplete · site search
Take a text query, return ranked relevant results. Inverted index, ranking algorithms (BM25, learning-to-rank), tokenization for the relevant languages. Typeahead and autocomplete add latency requirements. The 2026 default blends keyword search with vector embeddings.
Dominant conceptsSearch and indexing, vector databases (semantic search), caching (popular queries), sharding (by document), database selection (primary store + index).Pattern 06
E-commerce
Amazon · Shopify-like marketplace · eBay · Etsy
Catalogs, inventory, carts, checkout, payments, orders. Inventory must be accurate (no overselling), checkouts must be transactional, search must work, and the system must survive Black Friday. The depth probes are usually around inventory consistency, payment idempotency, and order workflows.
Dominant conceptsDatabase selection (transactional), caching (catalog), search and indexing, message queues (order workflows), rate limiting (checkout).Pattern 07
Collaborative Editing
Google Docs · Figma · Notion · Miro · multiplayer apps
Multiple users edit the same document simultaneously and see each other's changes in real time. The defining technical decision is conflict resolution: operational transformation (OT) or conflict-free replicated data types (CRDTs). Presence, cursors, and offline support add depth.
Dominant conceptsReplication and consistency (CRDTs), message queues (operation broadcast), database selection (operation log), websocket-style connections, caching (active document state).Pattern 08
Notification Systems
Push notifications · email at scale · SMS · in-app notifications
Send messages from the system to users across multiple channels. Throttling, batching, deduplication, user preferences, delivery tracking. The scale dimension is what makes this a system design problem rather than a feature: hundreds of millions of notifications per day with strict deliverability requirements.
Dominant conceptsMessage queues (delivery), rate limiting (per-user throttling), database selection (preferences and history), observability (deliverability), sharding (per-user notification log).Pattern 09
API Platform
Stripe · Twilio · public APIs at scale · webhook delivery systems
Build a service that other developers consume programmatically. Authentication, rate limiting, idempotency, webhooks, SDKs, observability for customers. The defining requirement: customer trust depends on consistency and uptime, so the system has to handle failure modes gracefully without exposing them.
Dominant conceptsRate limiting (per-API-key), message queues (webhook delivery), observability (customer-facing dashboards), database selection (transactional), replication (multi-region).Pattern 10
AI-Augmented Apps
RAG chatbots · AI search · agentic apps · semantic recommendation
The newer pattern, increasingly common in 2026 interviews. Retrieval over a corpus, embedding pipelines, LLM calls, hybrid keyword + vector search. The infrastructure overlaps with traditional patterns (caching, queues, databases) but adds embedding pipelines, vector stores, and LLM cost management as first-class concerns.
Dominant conceptsVector databases, search and indexing (hybrid retrieval), caching (query and embedding), rate limiting (LLM calls), observability (token cost and retrieval recall).03How the Patterns Map to Concepts
The patterns aren't standalone topics. Each one is a specific composition of concepts from the concept library. The matrix below shows which concepts dominate each pattern. Once you've worked through the concept deep-dives, you've already learned 80% of what you need for any pattern; what's left is knowing which concepts compose how.
Patterns × Concepts: Where Each Pattern Leans
Each row is a pattern, each column a concept. Dominant concepts (large terracotta dots) drive the architecture and the depth probes; supporting concepts appear in the design but don't define it. The same concept (caching) shows up across many patterns but means different things in each.
The same concept means different things
One thing the matrix understates: the same concept means different things across patterns. Caching in a social feed is timeline materialization (precomputed feeds in Redis); caching in search is query result caching; caching in video streaming is CDN edge caching. Same primitive, different specific use. Knowing the pattern tells you what specific kind of caching matters here.
This is why pattern recognition matters: the concept is necessary but not sufficient. You need to know which flavor of the concept the pattern requires.
04How to Use This Hub
If you're preparing for system design interviews, here's a four-step strategy that uses this hub effectively.
Step 01
Start with the framework, not the questions
The interview framework is the methodology that applies to every question. Until you've internalized the framework's four steps (clarify, decompose, deep-dive, evaluate), more questions don't help. Read the framework first; the questions are practice for the framework, not a substitute for it.
Step 02
Build concept fluency
Work through the concept library deep-dives in order. Caching, sharding, message queues, replication, and the rest. Each concept appears in multiple patterns; building fluency once pays off across every question. Most candidates over-invest in question-specific memorization and under-invest in concept depth. Flip that ratio.
Step 03
Learn the patterns, not the questions
Come back to this hub. Internalize the ten patterns. For each one, be able to name the canonical variants, the dominant concepts, and the depth probes that distinguish strong answers. This is where the compression happens: ten patterns is a manageable mental model, dozens of individual questions is not.
Step 04
Practice with worked examples, not pattern-matching
Once you have framework + concepts + patterns, work through specific questions. The goal isn't to memorize the answer; it's to practice applying the framework on a real question and notice how the patterns compose. Each pattern walkthrough we publish will use the framework explicitly so you can see the methodology in action.
The right preparation order is framework first, concepts second, patterns third, specific questions fourth. Most candidates do the reverse and run out of time.
05Where to Start
If you have time for only three patterns to internalize first, these are the three highest-leverage. Each one shows up in roughly half of senior system design interviews, in some variant.
Start here · #1
Social Feed
The most commonly asked pattern. Twitter, Instagram, Threads, LinkedIn — all variants. Walking through a feed design exercises the full concept stack: caching, sharding, message queues, database selection, replication. If you're solid on the social feed pattern, you're ready for many of the most-asked questions.
Start here · #2
Chat / Messaging
The other heavyweight. WhatsApp, Slack, Discord — variants of one core problem (reliable real-time message delivery at scale). Chat exercises websocket-style connections, message queues, replication, and presence systems. Many companies lean heavily on this pattern in interviews.
Start here · #3
Geospatial Dispatch
The third most common pattern, especially at companies adjacent to logistics or marketplaces. Uber, DoorDash, Yelp-nearby. Geospatial dispatch introduces concepts (geohashing, real-time location updates) that don't show up much elsewhere, so it's worth dedicated time.
After these three, the next priorities depend on the company you're interviewing with. Video streaming for FAANG roles touching media (YouTube, Netflix, Twitch). Search for any company where retrieval is core (Google, Amazon, e-commerce). E-commerce and notification systems are common at retail and consumer companies. Collaborative editing is increasingly common for product engineering roles. AI-augmented apps are the newest pattern and trending up; for any 2026 interview at an AI-forward company, this is now standard.
06Use This Hub Alongside
Methodology
The four-step methodology (clarify, decompose, deep-dive, evaluate) that applies to every system design question. Read this first; the patterns are what you apply the framework to.
Concept depth
Ten concept deep-dives covering caching, sharding, message queues, replication, search, observability, vector databases, and more. Each pattern is a specific composition of these concepts.
07Questions Hub FAQ
Are these the only patterns I need to know?
Roughly 95% of senior system design interviews map cleanly to one of these ten patterns. The remaining 5% are either company-specific deep questions (Netflix asking about their video pipeline specifically, Stripe asking about their payments infrastructure specifically) or genuinely novel problems. Those are rare and usually flagged in advance. If you're solid on these ten patterns plus the underlying concepts, you're well-prepared for the vast majority of what gets asked.
The interviewer asked me to design a system that doesn't fit any pattern. What do I do?
Look harder; almost every system design question fits one or more of these patterns at its core, even if the framing is unusual. "Design a system to detect credit card fraud in real time" is a notification systems pattern with a stream-processing twist. "Design a system to coordinate flight bookings" is e-commerce with a strong consistency twist. The framing changes; the underlying composition usually doesn't. If after careful thought it really doesn't fit any pattern, fall back to the framework: clarify the requirements, decompose the system, deep-dive the hard parts, evaluate the design.
Do I need to memorize specific architectures (Twitter's actual architecture, Uber's actual architecture)?
No. Memorizing real-world architectures is the wrong preparation strategy. Companies' actual systems are tuned for their specific scale and history; what worked at Twitter in 2014 is not what would be designed today, and what works at Uber for taxis isn't necessarily what would work for your specific variant. Interviewers can usually tell when a candidate is reciting a memorized architecture rather than reasoning from requirements; the memorized version has gaps that don't survive depth probes. Reason from the pattern and the requirements every time.
How do I know which pattern an interviewer wants me to apply?
Listen carefully to the question and clarify. "Design Twitter" is a social feed pattern. "Design a system that lets users follow other users and see their posts" is also a social feed pattern. "Design a real-time activity feed for an e-commerce site" is still a social feed pattern, just in a different context. The pattern is determined by the structure of the problem, not the company name. If you're unsure, naming candidate patterns out loud and asking the interviewer to confirm is a strong move ("This sounds like a social feed pattern with some search elements; should I focus on the feed mechanics?").
Should I prepare for AI-augmented apps if the company isn't an AI company?
Increasingly, yes. By 2026, AI-augmented features are appearing at companies across the industry: customer support chatbots, semantic search, AI-powered recommendations. Even non-AI-first companies routinely ask system design questions involving retrieval over a corpus, embedding pipelines, or LLM cost management. The AI-augmented apps pattern is one to know; it's not optional anymore.
What if my interview is for a backend role with no real-time requirements?
The patterns still apply, but the dominant concepts shift. A backend role at an enterprise SaaS company is more likely to lean on database selection, replication, observability, and API platform patterns than on geospatial dispatch or video streaming. Prioritize the patterns that match the company's domain. The good news: the framework is the same, and the underlying concepts overlap heavily across patterns, so preparation transfers.
How long should I spend on each pattern?
Roughly proportional to how often it shows up. Plan a few hours each on the top three (social feed, chat/messaging, geospatial dispatch) since they cover so much ground. An hour or two each on the remaining patterns is enough to internalize the structure. The goal isn't depth on every pattern; it's recognition. You should be able to look at any system design question and say "this is pattern X with these specific variations" within the first minute.
When will detailed walkthroughs for each pattern be published?
We're publishing walkthroughs for each pattern over time, starting with the highest-priority three (social feed, chat/messaging, geospatial dispatch). Each walkthrough applies the interview framework to a canonical question in the pattern, showing how the concepts compose end-to-end across a 50-minute interview arc. Check back for updates, or use the framework directly — the concept and pattern foundation is enough to construct strong answers without waiting for the walkthroughs.
