Top 25 System Design Interview Questions
25 hand-picked high-level and low-level system design questions, each with a real description, expected key points, and the concepts it teaches.
By DevsUnite · 25 Questions
Design a Rate Limiter
A rate limiter throttles the number of requests a client, user, or IP can send to a service within a time window, protecting backend systems from abuse, accidental traffic spikes, and denial-of-service attacks. It's one of the most commonly asked system design questions because it tests algorithmic thinking (the limiting algorithm itself) alongside distributed-systems thinking (making that algorithm work correctly across multiple servers).
A rate limiter throttles the number of requests a client, user, or IP can send to a service within a time window, protecting backend systems from abuse, accidental traffic spikes, and denial-of-service attacks. It's one of the most commonly asked system design questions because it tests algorithmic thinking (the limiting algorithm itself) alongside distributed-systems thinking (making that algorithm work correctly across multiple servers).
- Clarify limiter type: per-user, per-IP, per-API-key, or global, and where it sits (client, API gateway, or individual service)
- Compare limiting algorithms: token bucket, leaky bucket, fixed window counter, sliding window log, sliding window counter, and their memory/accuracy trade-offs
- Decide where state lives: in-memory (fast but not shared across servers) vs a centralized store like Redis (shared, adds network latency)
- Handle race conditions when multiple servers increment the same counter concurrently (atomic Redis operations, Lua scripts)
- Define the response contract: HTTP 429, Retry-After header, and whether to reject or queue excess requests
- Discuss distributed rate limiting across multiple data centers and clock-drift issues between servers
Token bucket, Sliding window counter, Redis, Distributed counters, API gateway, Atomic operations
Design TinyURL
TinyURL converts long URLs into short, unique aliases that redirect back to the original when visited. The core design challenge isn't storage. It's generating short, collision-free, unpredictable keys at scale and serving redirects with very low latency, since read traffic vastly outweighs write traffic.
TinyURL converts long URLs into short, unique aliases that redirect back to the original when visited. The core design challenge isn't storage. It's generating short, collision-free, unpredictable keys at scale and serving redirects with very low latency, since read traffic vastly outweighs write traffic.
- Estimate read:write ratio (typically 100:1 or higher) and design around read-heavy traffic
- Choose a short-key generation strategy: base62 encoding of an auto-incrementing ID, or a hash (MD5/SHA) truncated and checked for collisions
- Design the redirect endpoint for low latency: cache hot URLs (Redis/CDN), and weigh 301 vs 302 redirects (caching vs analytics trade-off)
- Plan the database schema and choose SQL vs NoSQL based on scale and query patterns
- Handle custom aliases, link expiration, and click analytics without slowing down the redirect path
- Discuss key-generation-service scaling: pre-generating and distributing key ranges to avoid a single point of contention
Base62 encoding, Hashing & collision handling, Caching (Redis/CDN), 301 vs 302 redirects, Read-heavy system design, Unique ID generation
Design Twitter
Twitter is a social platform for posting short messages (tweets) and following other users to see their posts in a personalized, roughly-chronological timeline. The hardest part is the fan-out problem: efficiently delivering a tweet from one user to potentially millions of followers' timelines without either write or read latency exploding.
Twitter is a social platform for posting short messages (tweets) and following other users to see their posts in a personalized, roughly-chronological timeline. The hardest part is the fan-out problem: efficiently delivering a tweet from one user to potentially millions of followers' timelines without either write or read latency exploding.
- Define core features in scope: post tweet, follow/unfollow, home timeline, like/retweet, and explicitly what's out of scope
- Design the fan-out strategy: fan-out-on-write (push to followers' timelines at post time) vs fan-out-on-read (compute timeline at read time) vs a hybrid for celebrity accounts
- Handle the 'celebrity problem': a user with millions of followers makes pure fan-out-on-write impractical
- Design the data model for tweets, follow graph, and timelines, and pick storage suited to each access pattern
- Discuss caching the home timeline and invalidation when new tweets arrive
- Address search and trending topics as a separate, eventually-consistent subsystem
Fan-out on write vs read, Timeline generation, Follow graph, Caching, Eventual consistency, Celebrity/hot-key problem
Log in to save your progress and notes to your account.
Frequently asked questions
What is the System Design Sheet?
A curated set of high-level (HLD) and low-level (LLD) system design interview questions, designing systems like a rate limiter, TinyURL, and Twitter, each with a real description of the problem, the key points a strong answer should cover, the concepts it teaches, the companies known to ask it, and a reference article and video.
How many questions does it have?
25 questions, a mix of high-level and low-level design problems, hand-picked from a broader list of 32 for the strongest, least-redundant coverage.
Is it free to use?
Yes. Browsing every problem on this page is completely free, with no account required. Creating a free DevsUnite account lets you save your checked-off progress, star favorites, and add personal notes that sync across devices.
Do I need an account to track my progress?
You can read and solve every problem without logging in. An account is only required to mark a problem as done, star it, or add a note. Those actions save to your account instead of resetting on refresh.