OneNoughtOne
0/273
Loading content...
Read aloud is unavailable in this browser.
Deliberate practice separates those who become exceptional from those who plateau. In system design interviews, this means more than randomly picking problems and attempting solutions. It requires a strategic approach: carefully selecting problems that target specific skills, progressively increasing difficulty, and ensuring comprehensive coverage of the problem landscape you'll encounter in real interviews.
This page provides a curated, extensively annotated catalog of practice problems organized to maximize your learning efficiency. Each problem is analyzed for the core concepts it exercises, the architectural patterns it demands, and the common pitfalls that trip up candidates. More importantly, you'll learn how to approach this list—not as a checklist to complete, but as a framework for systematic skill building.
By the end of this page, you will possess a comprehensive practice roadmap spanning beginner to expert-level problems. You'll understand which problems to tackle first, which concepts each problem reinforces, and how to structure a practice regimen that builds toward interview readiness without burning out or wasting time on low-value exercises.
System design problems don't exist in isolation—they cluster into recognizable categories that share underlying architectural patterns. Understanding these categories allows you to transfer knowledge between problems and recognize familiar patterns in novel contexts.
Why categorization matters:
When you solve a URL shortener, you're not just learning about URL shorteners—you're learning about distributed ID generation, read-heavy workloads, caching strategies, and analytics at scale. When you later encounter a 'design a paste bin' or 'design a QR code generator,' you'll recognize the structural similarity and apply the same architectural skeleton.
Mastering categories, not just individual problems, is the difference between learning 20 isolated solutions and developing transferable architectural intuition.
| Category | Defining Characteristics | Representative Problems | Key Skills Exercised |
|---|---|---|---|
| Data-Intensive Systems | High read/write throughput, storage at scale, efficient retrieval | Key-Value Store, Distributed Cache, Time Series DB | Partitioning, replication, consistency models, indexing |
| Social & Feed Systems | Graph relationships, personalized content, real-time updates | Twitter, Facebook Feed, LinkedIn Connections | Fan-out strategies, ranking algorithms, graph storage |
| Messaging & Real-Time | Low latency, delivery guarantees, presence management | WhatsApp, Slack, Discord Voice Chat | WebSockets, message queues, delivery semantics |
| Media & Content | Large file handling, transcoding, streaming, CDN integration | YouTube, Netflix, Instagram, Spotify | Chunked uploads, adaptive bitrate, content delivery |
| E-Commerce & Transactions | Inventory, payments, eventual consistency, business logic | Amazon, Payment System, Booking.com | Saga patterns, idempotency, fraud detection |
| Search & Discovery | Full-text search, autocomplete, ranking, personalization | Google Search, Typeahead, Recommendation Engine | Inverted indexes, tries, ML integration |
| Location-Based Services | Geospatial queries, proximity matching, real-time tracking | Uber, Google Maps, Yelp | Geohashing, spatial indexes, ETA calculation |
| Infrastructure Systems | Internal tools, monitoring, rate limiting, orchestration | Rate Limiter, Metrics System, Job Scheduler | Token buckets, time-series storage, coordination |
Cross-cutting concerns:
Every system design problem, regardless of category, will exercise certain universal concerns:
As you practice, consciously identify which categories your problems fall into and which cross-cutting concerns dominate. This meta-awareness accelerates pattern recognition in real interviews.
When you encounter a new problem, spend the first 30 seconds categorizing it. Ask: 'Is this fundamentally a feed problem? A messaging problem? A data-intensive storage problem?' This immediately unlocks a set of relevant patterns and helps you structure your initial thoughts.
Start here regardless of your experience level. Foundational problems teach essential building blocks that appear in every advanced design. They're deceptively simple on the surface, but depth emerges as you consider scale, edge cases, and production-grade requirements.
Each problem below is annotated with the concepts it teaches, common interview variations, and the key insights that distinguish strong answers.
Resist the urge to rush through foundational problems. Spend 2-3 sessions on each, exploring different angles. A URL shortener can be a 30-minute sketch or a 90-minute deep dive into global distribution, analytics pipelines, and abuse prevention. The depth you develop here pays dividends in advanced problems.
Intermediate problems combine multiple building blocks and introduce real-world complexity. They require you to make explicit trade-off decisions and defend them. Interviewers expect you to discuss alternatives and explain why you chose one approach over another.
These problems are the core of typical system design interviews at senior engineering levels (L5-L6 at FAANG companies).
At the intermediate level, interviewers expect you to explicitly state trade-offs: 'I'm choosing fan-out on write because our usage pattern shows most users have <1000 followers, but I acknowledge this breaks down for celebrity accounts.' Never present a design as 'the only way.' Show you understand what you're giving up.
Advanced problems involve significant ambiguity, complex distributed systems concerns, and nuanced trade-offs. They require you to make assumptions, explore multiple valid approaches, and demonstrate deep understanding of distributed systems principles.
These problems appear in Staff/Principal-level interviews (L6+ at FAANG) and expect sophisticated architectural reasoning.
At this level, problems are intentionally ambiguous. State your assumptions explicitly: 'I'm assuming we need sub-100ms p99 latency for search,' or 'I'm designing for a write-heavy workload based on the requirement for real-time collaboration.' This shows maturity and prevents wasted time on misaligned designs.
Expert problems represent the highest difficulty tier. They often involve designing core infrastructure, greenfield distributed systems, or solving problems with no established 'textbook' solution. These appear in Distinguished Engineer / Fellow-level interviews and require synthesis of deep technical expertise with business and organizational awareness.
Additional expert problems to explore:
These problems require you to synthesize everything you've learned and often involve inventing solutions rather than applying known patterns.
Strategic practice beats random grinding. With the problem list in hand, the question becomes: how do you structure practice to maximize learning per hour invested?
The following framework ensures comprehensive coverage while building progressively toward interview readiness.
| Phase | Duration | Focus | Problems Per Week | Key Activities |
|---|---|---|---|---|
| Foundation | 2-3 weeks | Core building blocks, no time pressure | 2-3 | Untimed practice, written designs, extensive notes |
| Expansion | 3-4 weeks | Intermediate problems, trade-off articulation | 2-3 | Timed practice (50 min), self-recording, pattern journaling |
| Integration | 2-3 weeks | Advanced problems, connecting concepts | 2 | Mock interviews, peer practice, multi-angle exploration |
| Refinement | 1-2 weeks | Polish delivery, handle variations | 1-2 | Full mock interviews, targeted weak-spot practice |
Revisit problems you've 'completed' after 1-2 weeks. Can you still articulate the design without notes? Do you remember the key trade-offs? Spaced repetition converts short-term recognition into long-term architectural intuition.
Not all problems are equally valuable for all candidates. Your specific target company, role level, and existing experience should guide problem selection.
Gap-based selection:
Identify your weak areas honestly. If you've never designed a real-time system, prioritize messaging and collaboration problems. If your database knowledge is shallow, tackle the distributed database and key-value store. If you always struggle with estimation, frontload problems that demand careful back-of-envelope math.
The goal isn't to practice what's comfortable—it's to systematically close competency gaps.
Memorizing 'the answer' to specific problems is counterproductive. Interviewers often add twists, change requirements mid-design, or ask completely novel problems. Focus on understanding why designs work, not what the specific design is. The principles transfer; the specifics don't.
We've constructed a comprehensive practice roadmap. Let's consolidate the key takeaways:
What's next:
With a problem list in hand, you need a framework for evaluating your practice attempts. The next page provides detailed self-evaluation criteria—rubrics you can apply to your own designs to identify strengths, uncover blind spots, and track improvement over time.
You now have a strategically curated practice problem list spanning beginner to expert levels. Each problem is annotated with learning objectives, key decisions, and distinguishing insights. Use this as your roadmap for deliberate, systematic practice toward interview mastery.