Most Asked System Design Questions at Top Tech Companies (2025)

System design interviews feel infinite until you notice the pattern: the same twenty or so questions get asked over and over, dressed up in different company names. Design Twitter becomes 'design a social feed.' Design WhatsApp becomes 'design a real-time messaging system.' Once you've solved the underlying problem once, you can answer five different-sounding questions with the same reasoning.

This is a curated list of the questions that show up most often at top tech companies, grouped by how likely you are to face them. For each one, we call out the core challenge the interviewer is actually testing and the specific architecture decisions that separate a strong answer from a generic one.

Practice with a timer. For each question below, run a 45-minute timed session in LLDCanvas Interview Mode before checking the model answer.

01Tier 1: Must Know

These five come up constantly because each one forces a genuinely hard trade-off, not just a list of components. If you can defend the decisions below out loud, you can handle most variations interviewers throw at you.

1. Design Twitter / X

Core challenge: generating a home timeline for 500M+ users where reads vastly outnumber writes, and a small number of accounts have tens of millions of followers.

• Fan-out on write: push each new tweet into every follower's precomputed timeline cache. Reads become a single cache lookup, but posting is expensive when the author has millions of followers.
• Fan-out on read: merge tweets from all followed accounts at request time. Writes stay cheap, but a user following thousands of accounts pays for it on every page load.
• Hybrid (Twitter's actual approach): fan-out on write for regular accounts; skip fan-out entirely for celebrity accounts above a follower threshold and merge their tweets into the timeline at read time instead.
• Timelines are stored as bounded lists (recent N tweet IDs) in Redis, not full tweet objects, keeping the fan-out write cheap and the cache small.
• Tweet IDs are generated with a Snowflake-style scheme so they are roughly time-sortable without a central counter.

2. Design WhatsApp

Core challenge: deliver messages in order, in real time, to billions of devices that connect and disconnect constantly, without losing a message when a recipient is offline.

• Persistent WebSocket connections per device instead of polling, so the server can push messages the instant they arrive.
• Routing path: sender's client to a WebSocket server to a routing/session service that looks up which server the recipient is connected to (or queues for push notification if offline).
• Presence is a heartbeat mechanism: each client pings periodically, and online/offline state is tracked as a short-TTL key in Redis rather than a persistent database row.
• Storage: Cassandra, chosen because message history is write-heavy, append-only, and accessed almost entirely in time order per conversation - a pattern wide-column stores handle far better than a relational database.

3. Design YouTube

Core challenge: the upload path and the playback path have opposite traffic shapes - uploads are write-heavy and can tolerate latency, playback is read-heavy at massive scale and cannot.

• Upload pipeline: raw video lands in object storage, then a transcoding service (often chunked and parallelized) produces multiple resolutions and bitrates asynchronously.
• Adaptive streaming: HLS or DASH manifests let the client switch bitrate mid-playback based on measured network conditions.
• Encoded video files live in S3/GCS behind a CDN; metadata (title, description, view counts, upload status) lives in PostgreSQL.
• View counts are updated through an approximate, batched counter rather than an increment-per-view write, since exact real-time counts aren't worth the write contention.

4. Design Uber

Core challenge: matching riders to drivers in real time using continuously moving location data, at a scale where naive polling or full-table geo-queries fall over.

• Driver location updates every 4-5 seconds flow through Kafka for ingestion, decoupling the write rate from downstream matching logic.
• Nearby-driver queries use Redis Geo (geohash-based indexing) so 'find drivers within 2km' is a fast range query instead of a scan.
• The trip is modeled as an explicit state machine: REQUESTED -> DRIVER_ASSIGNED -> DRIVER_ARRIVED -> IN_PROGRESS -> COMPLETED, which makes edge cases (cancellations, timeouts) tractable to reason about.
• Surge pricing is computed per geohash cell from the live supply/demand ratio, recalculated on a short interval (about every minute) rather than continuously.

5. Design Instagram

Core challenge: the same feed fan-out problem as Twitter, plus two extra wrinkles - content that expires and a discovery feed that isn't chronological at all.

• Feed generation mirrors Twitter's hybrid fan-out model: precomputed for most accounts, merged at read time for very large accounts.
• Stories expire automatically: stored with a 24-hour TTL directly in Redis, with 'viewed by' tracking implemented as a Redis Set per story.
• Explore/discovery is not real-time at all - it's built by an offline collaborative-filtering pipeline that recomputes recommendations daily and serves them from a precomputed cache.

02Tier 2: Frequently Asked

This tier trades scale for precision - each question is narrower than a Tier 1 system, but tests a specific mechanism in depth. Interviewers use these to check whether you actually understand a concept or just name-drop it.

6. Design a URL Shortener

Core challenge: an extremely read-heavy service (redirects vastly outnumber creations) that needs short, unique, non-guessable-enough codes at scale.

• Base62 encoding of an auto-incrementing ID is the standard answer - short, collision-free by construction, no coordination needed beyond the ID generator.
• The alternative, hashing the URL (MD5/SHA) and truncating, requires a collision-check step and is usually the weaker answer unless you also justify it.
• Redirects are cached aggressively (Redis or CDN edge) since the read:write ratio is typically 100:1 or higher.

7. Design a Rate Limiter

Core challenge: enforcing a request limit accurately when the limiter itself is distributed across many nodes, so counters must stay consistent without becoming a bottleneck.

• Token bucket is the algorithm of choice - it allows short bursts while enforcing a steady average rate, and is simple to reason about.
• The check-and-decrement has to be atomic across concurrent requests hitting different app servers, so it's implemented as a Lua script executed inside Redis, not as separate GET/SET calls from the app.
• Sliding-window counters are a common follow-up discussion when the interviewer pushes on fixed-window edge effects (bursts at window boundaries).

8. Design Google Drive

Core challenge: syncing files across multiple devices efficiently, without re-uploading unchanged data and without corrupting files when two devices edit at once.

• Files are split into fixed-size chunks; only changed chunks are re-uploaded on an edit, not the whole file.
• Chunks are deduplicated by content hash - if two users upload the same file, or a file barely changes, the storage layer skips the redundant write.
• Conflicts are surfaced (versioned copies) rather than silently merged, since automatic merge is unsafe for arbitrary binary files.

9. Design a Notification Service

Core challenge: fanning a single event out to multiple channels (push, email, SMS, in-app) reliably, when each channel has different latency, failure modes, and rate limits.

• A single event is published to Kafka, then routed into channel-specific queues so a slow or failing email provider can't back up push notifications.
• Each channel worker handles its own retry policy and dead-letter queue independently.
• User preferences (which channels, quiet hours) are checked before fan-out, not after, to avoid wasted work.

10. Design Search Autocomplete

Core challenge: returning prefix matches in well under 100ms, at a query volume where hitting a database per keystroke is not an option.

• An in-memory trie keyed by prefix is the standard data structure - lookups are O(length of prefix), independent of dataset size.
• The trie is pre-computed from query logs, ranked by historical frequency, and rebuilt periodically rather than updated on every query.
• Personalization (recent searches, location) is layered on top of the global trie result rather than replacing it.

03Tier 3: Good to Know

These are less likely to be the headline question, but they show up as components inside Tier 1 and Tier 2 answers, or as a quick warm-up question before the main one.

• Distributed Cache (Redis-like): consistent hashing for key distribution, eviction policies (LRU/LFU), and replication for availability.
• Message Queue (Kafka-like): partitioned log storage, consumer groups for parallel processing, and offset tracking for at-least-once delivery.
• Web Crawler: a Bloom filter for cheap URL-seen deduplication, plus politeness controls (per-domain rate limiting) to avoid hammering any single site.
• Real-time Leaderboard: Redis Sorted Sets (ZADD/ZRANK) give O(log n) rank updates and range queries for free.
• API Gateway: a single entry point handling routing, authentication, rate limiting, and logging so individual services don't reimplement them.

04Quick Reference

05How to Structure Your Prep

Trying to prepare all fifteen-plus questions in parallel is how most candidates run out of time. A staged plan works better: Week 1 - master the five Tier 1 questions; they cover roughly 80% of the patterns you'll be tested on. Week 2 - work through Tier 2, where each question introduces exactly one new concept on top of what you already know. Week 3 onward - shift entirely to timed mock interviews using LLDCanvas's Interview Mode.

Within each mock session, keep a fixed time budget so you build the instinct for pacing under real interview pressure:

1. 5 min - requirements clarification (functional and non-functional)
2. 3 min - scale estimation (back-of-envelope numbers for QPS, storage, bandwidth)
3. 5 min - API design
4. 20 min - high-level architecture
5. 10 min - deep dive on two components the interviewer cares about most
6. 2 min - trade-offs and follow-up questions

Start with LLDCanvas's practice problems, then move to timed sessions in Interview Mode once the fundamentals feel solid.

06Conclusion

System design interviews reward pattern recognition more than raw memorization. The list of building blocks - fan-out strategies, geo-indexing, chunked uploads, token buckets, tries - is finite, and it repeats across nearly every question a top tech company will ask. Once you've internalized why each decision was made, not just what it is, you can adapt to a question you've never seen before.

Work through the tiers in order, be able to justify every architecture decision out loud, and put yourself under a timer before the real interview does it for you. For the underlying framework these questions all draw on, see the complete system design interview guide.