System Design Interview: A Step-by-Step Framework + 15 Practice Problems

A system design interview asks you to design a large software system, such as a URL shortener, a chat app or a payment service, in about 45 minutes, while explaining your choices out loud. You are not expected to produce the "right" architecture. You are expected to ask good questions, size the problem, draw a design that works, and defend the trade-offs when the interviewer pushes.

This guide gives you a repeatable 7-step framework with a time budget for each step and phrases you can actually say, the system design concepts you need (load balancers, caching, sharding, consistent hashing, CAP and PACELC, queues, rate limiting, idempotency), a back-of-the-envelope estimation cheat sheet, and 15 practice problems with the two or three ideas each one is really testing.

It is written for backend developers with 1 to 8 years of experience, and for freshers who are meeting system design for the first time. The examples lean towards Java and Spring Boot because that is what most of our readers use, but the framework works in any language.

In this guide

• What a system design interview is really testing
• How to approach a system design interview: the 7-step framework
• Back-of-the-envelope estimation cheat sheet
• System design concepts you must know
• 15 system design interview questions to practice
• Mistakes that cost candidates the offer
• A four-week practice plan
• Practice with the full question bank
• Related reading
• FAQ

What a system design interview is really testing

What is a system design interview?

It is an open-ended conversation in which you design a system end to end: what it does, how big it is, its API and data, the main components, and how it behaves when traffic grows or parts fail. There is no single correct answer. The interviewer watches how you reason, not whether you match a reference diagram.

Most companies call this round "high level design" (HLD). A separate "low level design" (LLD) round asks you to model classes and interfaces for something like a parking lot. This guide is about HLD; for the class-level round, see our low-level design interview guide in Java.

How is a system design interview scored?

Rubrics differ between companies, but they usually look for the same four things: you scope the problem before solving it, you produce a design that actually meets the requirements, you go deep on at least one hard part with real technical detail, and you communicate clearly, including when you change your mind.

Notice what is missing: naming the most tools. Saying "Kafka, Redis, Cassandra, Kubernetes" in the first five minutes earns nothing. Saying "writes are 1% of traffic, so a single primary database is fine for now and the hard part is the read path" earns a lot.

What the interviewer is checking: can this person take a vague business problem, turn it into concrete requirements and numbers, and make sensible trade-offs without being led by the hand?

Is system design different for freshers, mid-level and senior engineers?

Yes, mainly in depth and ownership. A fresher or junior candidate is expected to know the building blocks and draw a reasonable design with some help. A mid-level engineer should drive the conversation and handle one or two deep dives. A senior engineer should lead the whole session, spot the real bottleneck early, discuss failure modes and operations (monitoring, rollout, cost), and explain what they would build first and what can wait.

How to approach a system design interview: the 7-step framework

The biggest reason candidates fail is not missing knowledge. It is running out of time with the interesting part untouched, or diving into database indexes before anyone knows what the system does. A fixed structure fixes both. Here is the budget for a 45-minute round; for a 60-minute round, give the extra time to the deep dives.

Step 1: Clarify requirements (0 to 5 minutes)

Turn the one-line prompt into a short, written list of requirements. Split them into functional requirements (what the system does) and non-functional requirements (how well it must do it). Then say what you are leaving out.

• Functional: the 3 to 5 core use cases. For a chat app: one-to-one messages, group messages, online status, message history. Not voice calls, unless asked.
• Non-functional: scale (users, requests), latency targets, availability, consistency needs, durability. "Can we ever lose a message?" is a better question than "how many servers?"
• Out of scope: say it out loud and write it down, so the interviewer can object now rather than at minute 35.

Useful phrases: "Before I design anything, can I confirm the main use cases?", "Is this read-heavy or write-heavy?", "Which matters more here if we have to choose: always accepting writes, or never showing stale data?", "I will leave analytics out unless you want it in."

What the interviewer is checking: do you ask questions that change the design? "What is the read to write ratio?" changes the design. "What color is the button?" does not.

Step 2: Back-of-the-envelope estimation (5 to 9 minutes)

Estimate requests per second, peak load, storage over a few years and, if relevant, bandwidth. The goal is not precision. The goal is to learn which part of the system is big. Round aggressively, state every assumption, and do the arithmetic on the whiteboard where the interviewer can follow it.

A typical sequence: daily active users, times actions per user per day, divided by about 100,000 seconds in a day, gives average QPS. Multiply by 2 to 3 for peak. Multiply writes per day by object size and by days kept for storage. If the numbers say "40 writes per second and 3 TB in five years", you have learned that a single relational database can probably take the writes, and that storage, not throughput, may decide the database choice later.

Step 3: Define the API (9 to 13 minutes)

Write 3 to 5 endpoints with their inputs and outputs. This pins down the contract between the client and your system, and it often exposes missing requirements. For a URL shortener:

• POST /api/links with { "url": "...", "alias": "optional", "expiresAt": "optional" } returns 201 and { "code": "aZ3kQ9x" }.
• GET /{code} returns a 302 redirect with a Location header, or 404.
• GET /api/links/{code}/stats returns click counts.

Mention pagination for list endpoints (cursor-based beats offset-based at scale), authentication, and an idempotency key on endpoints that create money-like things, such as payments or orders. REST is a safe default; mention WebSockets when the server must push (chat, live location), and gRPC for internal service-to-service calls if you like.

Step 4: Sketch the data model (13 to 17 minutes)

List the main entities, their key fields, and, most importantly, the access patterns: how will you read this data? The primary key and the partition key should come straight from the most common query. If every redirect reads a link by its short code, then the short code is the key. If a chat app always loads "the last 50 messages in conversation X", then messages are partitioned by conversation and sorted by time.

This is also where you make a first database choice and say why. "Links are simple key lookups with no joins, but I want a uniqueness constraint on the code, so I will start with PostgreSQL and revisit if storage grows past one node" is a complete, defensible answer.

Step 5: Draw the high-level design (17 to 27 minutes)

Draw the boxes and arrows for the happy path, then walk one request through it end to end: client, load balancer, service, cache, database, and any asynchronous path through a queue. Keep services coarse at this point. Three boxes that you can explain beat twelve boxes you cannot.

Say what each component is for and why it is there. "The redirect service is stateless, so we can run as many copies as we need behind the load balancer" is the kind of sentence that earns points. Before moving on, check your design against the requirements from step 1, one by one.

Step 6: Deep dives (27 to 40 minutes)

Pick the two or three hardest parts and go deep. Often the interviewer will choose; if not, choose yourself and say why. Good deep dives are about the thing that is special to this problem: ID generation for a URL shortener, fan-out for a news feed, double-booking for ticket sales, exactly-once effects for payments, connection management for chat.

For each deep dive, give at least two options, compare them, pick one, and name what it costs. Then talk about failure: what happens if this node dies, this queue backs up, or this cache is cold? Interviewers remember candidates who raise failure modes before being asked.

What the interviewer is checking: technical depth. Can you go below the box labeled "cache" and talk about TTLs, invalidation, stampedes and hit ratio, with numbers?

Step 7: Bottlenecks, trade-offs and wrap-up (40 to 45 minutes)

Summarize the design in three sentences, list the main trade-offs you made, and say what breaks first at 10 times the load and how you would fix it. Mention monitoring (latency percentiles, error rate, queue lag, cache hit ratio) and one or two things you would build later. Ending with a clear summary is much stronger than ending mid-sentence on a database index.

Back-of-the-envelope estimation cheat sheet

You need a handful of numbers in your head. Everything else you can derive. The latency figures are orders of magnitude, not benchmarks; real hardware varies, and the point is the ratios between them.

The same data as a list:

• Time: 1 day is 86,400 seconds, call it 10^5. One month is about 2.6 million seconds.
• Traffic: 1 million requests a day is about 12 per second. 100 million a day is about 1,200 per second. 1 billion a day is about 12,000 per second. Assume peak is 2 to 3 times the average and say so.
• Size: 2^10 is about a thousand (KB), 2^20 about a million (MB), 2^30 about a billion (GB), 2^40 about a trillion (TB). One million items of 1 KB is 1 GB; one billion is 1 TB.
• Latency (rough): L1 cache about 1 ns, main memory about 100 ns, SSD random read about 100 µs, round trip inside one data center about 0.5 ms, HDD seek about 10 ms, round trip between continents about 150 ms.

How do you do back-of-the-envelope estimation in an interview?

Start from users and actions, convert per-day numbers to per-second by dividing by 10^5, multiply by a peak factor, then multiply by object size and retention for storage. Round every number to one significant figure and keep units on the board. Then say what the number means for the design.

Worked example: a photo-sharing app with 10 million daily active users, each viewing 50 photos and uploading 0.2 photos a day.

• Reads: 10 M × 50 = 500 M a day, about 5,000 per second on average, roughly 15,000 at peak.
• Writes: 10 M × 0.2 = 2 M uploads a day, about 20 per second.
• Storage: 2 M × 2 MB = 4 TB a day, roughly 1.5 PB a year before replication.
• Conclusion: reads outnumber writes 250 to 1, so caching and a CDN are essential; photo bytes go to object storage, not the database; the metadata database is small by comparison.

That last line is the point of the exercise. An estimate that does not change a decision is wasted time.

System design concepts you must know

Almost every design is built from the same dozen blocks. You do not need to know their internals in depth, but you must know what each one is for, what it costs and how it fails. Here is the generic architecture most answers start from.

What does a load balancer do?

A load balancer spreads incoming requests across several servers and stops sending traffic to servers that fail health checks. That lets you scale out by adding servers and survive the loss of one. Layer 4 balancers route by IP and port; layer 7 balancers understand HTTP and can route by path or header, terminate TLS and retry idempotent requests.

Common algorithms are round robin, least connections, and hashing on a key when you need the same client to land on the same server. The load balancer itself must not be a single point of failure, so it runs as a redundant pair or as a managed cloud service. The design rule that makes all of this work is keeping app servers stateless: session data lives in a shared store or in a signed token, never in one server's memory.

When should you add a cache, and which caching strategy should you use?

Add a cache when the same data is read far more often than it changes and the database or a downstream service is the bottleneck. The default pattern is cache-aside: read from the cache, on a miss read the database and put the result in the cache with a TTL; on a write, update the database and then delete the cache key.

Other patterns: write-through (write to cache and database together, so reads are always warm) and write-behind (write to the cache and flush to the database later, which is fast but can lose data). Know the classic failure modes:

• Stampede: a hot key expires and thousands of requests hit the database at once. Fix it with a per-key lock or request coalescing, and add random jitter to TTLs.
• Penetration: requests for keys that do not exist always miss. Cache the "not found" result briefly, or use a Bloom filter.
• Stale data: decide how stale is acceptable, and delete rather than update cache entries on writes to avoid races.

When memory fills up, the cache evicts keys. Redis, the usual choice, offers policies such as allkeys-lru and allkeys-lfu; the Redis eviction documentation explains when each fits.

What is a CDN and when does it help?

A content delivery network is a set of edge servers around the world that cache your static and cacheable content close to users. It cuts latency for distant users and takes load off your origin. Use it for images, video segments, JavaScript and CSS, and for API responses that are the same for many users and can carry a Cache-Control header. The origin is usually object storage. Remember that changing cached content requires versioned file names or an invalidation.

SQL or NoSQL: how do you choose a database?

Choose from the access patterns and consistency needs, not from fashion. A relational database such as PostgreSQL or MySQL is the right default when you need transactions, constraints, joins and flexible queries, and it handles far more load than many candidates assume, especially with read replicas and good indexes. A key-value or wide-column store (DynamoDB, Cassandra) fits very large datasets with simple, known access patterns and very high write rates. A document store fits nested, schema-flexible records. Search engines, time-series databases and object storage solve their own specific problems.

A good interview answer names the access pattern first: "We only ever read a conversation's messages by conversation id and time, at very high write volume, so a wide-column store partitioned by conversation id fits well."

What is the difference between replication and sharding?

Replication copies the same data to several machines; sharding splits different data across machines. Replication gives you read scaling and failover. Sharding gives you write scaling and more total storage. Large systems use both: each shard is replicated.

With leader-follower replication, writes go to the leader and are copied to followers, usually asynchronously, so a read from a follower can be slightly stale (replication lag). If a user must see their own write, read it from the leader or wait for the follower to catch up. With sharding, the shard key decides everything: a good key spreads load evenly and keeps the common query on one shard. A bad key creates hot shards or forces every query to touch all shards. Changing the number of shards is painful with simple modulo hashing, which is exactly the problem consistent hashing solves.

What is consistent hashing?

Consistent hashing places both servers and keys on a hash ring; each key belongs to the first server clockwise from it. When you add or remove a server, only the keys in the arcs next to it move, about 1/N of them for N servers, instead of almost all keys with hash(key) % N. Virtual nodes, many ring positions per server, keep the load even.

Here is a small, complete Java program that shows it. It assigns 100,000 keys to servers A, B and C, adds server D, and counts how many keys had to move with three strategies. It uses a TreeMap as the ring, because ceilingEntry gives you "the first node clockwise" in O(log n).

import java.nio.charset.StandardCharsets;
import java.security.MessageDigest;
import java.util.*;

public class ConsistentHashing {

    // 64-bit position from the first 8 bytes of MD5: well spread, stable across JVMs
    static long hash(String s) {
        try {
            byte[] d = MessageDigest.getInstance("MD5").digest(s.getBytes(StandardCharsets.UTF_8));
            long h = 0;
            for (int i = 0; i < 8; i++) h = (h << 8) | (d[i] & 0xff);
            return h;
        } catch (Exception e) {
            throw new IllegalStateException(e);
        }
    }

    static final class Ring {
        private final TreeMap<Long, String> ring = new TreeMap<>();
        private final int vnodes;

        Ring(int vnodes, String... nodes) {
            this.vnodes = vnodes;
            for (String n : nodes) add(n);
        }

        void add(String node) {
            for (int i = 0; i < vnodes; i++) ring.put(hash(node + "#" + i), node);
        }

        String nodeFor(String key) {
            // first virtual node clockwise from the key; wrap to the start of the ring
            Map.Entry<Long, String> e = ring.ceilingEntry(hash(key));
            return (e != null ? e : ring.firstEntry()).getValue();
        }
    }

    static final int KEYS = 100_000;

    static void report(String label, Map<String, String> before, Map<String, String> after) {
        Map<String, Integer> load = new TreeMap<>();
        after.values().forEach(n -> load.merge(n, 1, Integer::sum));
        long moved = before.keySet().stream().filter(k -> !before.get(k).equals(after.get(k))).count();
        System.out.printf("%-26s load after adding D: %s%n", label, load);
        System.out.printf("%-26s keys moved: %,d of %,d (%.1f%%)%n%n", "", moved, KEYS, 100.0 * moved / KEYS);
    }

    public static void main(String[] args) {
        List<String> keys = new ArrayList<>();
        for (int i = 0; i < KEYS; i++) keys.add("user:" + i);

        // 1. hash(key) % N
        Map<String, String> modBefore = new HashMap<>(), modAfter = new HashMap<>();
        String[] three = {"A", "B", "C"}, four = {"A", "B", "C", "D"};
        for (String k : keys) {
            modBefore.put(k, three[(int) Math.floorMod(hash(k), 3L)]);
            modAfter.put(k, four[(int) Math.floorMod(hash(k), 4L)]);
        }
        report("hash % N", modBefore, modAfter);

        // 2 and 3. consistent hashing with 1 and with 200 virtual nodes per server
        for (int v : new int[] {1, 200}) {
            Ring ring = new Ring(v, "A", "B", "C");
            Map<String, String> before = new HashMap<>(), after = new HashMap<>();
            keys.forEach(k -> before.put(k, ring.nodeFor(k)));
            ring.add("D");
            keys.forEach(k -> after.put(k, ring.nodeFor(k)));
            report("ring, " + v + " vnode(s)/server", before, after);
        }
    }
}

Real output on JDK 25 (java ConsistentHashing.java):

hash % N                   load after adding D: {A=24921, B=24851, C=25194, D=25034}
                           keys moved: 74,977 of 100,000 (75.0%)

ring, 1 vnode(s)/server    load after adding D: {A=3057, B=1332, C=40206, D=55405}
                           keys moved: 55,405 of 100,000 (55.4%)

ring, 200 vnode(s)/server  load after adding D: {A=26701, B=26449, C=26320, D=20530}
                           keys moved: 20,530 of 100,000 (20.5%)

Three lessons sit in those six lines. Modulo hashing moves 75% of keys when going from 3 to 4 servers, which for a cache means a sudden flood of misses. A ring with one point per server moves fewer keys but is badly unbalanced: server D alone took 55% of all keys. With 200 virtual nodes per server, only 20.5% of keys moved (the ideal is 25%) and the load stayed even. Amazon's Dynamo paper describes the same idea, and Cassandra and many caches use variations of it.

What is the CAP theorem, and what does PACELC add?

The CAP theorem says that when a network partition splits a distributed system, it must choose between consistency (every read sees the latest write) and availability (every request gets a non-error answer). Partitions are not optional in real networks, so the real choice is C or A during a partition.

PACELC, proposed by Daniel Abadi, adds the part that matters every day: if there is a Partition, choose Availability or Consistency; Else, even when everything is healthy, choose Latency or Consistency. Synchronous replication across regions buys consistency with latency on every write. Abadi's PACELC paper puts Dynamo-style stores such as Cassandra in the PA/EL group in their default configuration. In an interview, apply it per feature: a bank balance needs consistency; a like counter can be eventually consistent.

Why use a message queue?

A queue or log (Kafka, RabbitMQ, SQS) decouples the service that produces work from the service that does it. The producer answers the user immediately; workers process at their own pace, absorb traffic spikes, and retry failures. Typical uses: sending emails and push notifications, resizing images, updating search indexes and analytics, and propagating events between microservices.

The trade-offs to mention: most queues deliver at least once, so consumers must be idempotent; ordering is usually guaranteed only per partition or per key; and you need a dead-letter queue for messages that keep failing, plus a metric for consumer lag.

How does rate limiting work?

A rate limiter caps how many requests a client can make in a time window and rejects the rest with HTTP 429 Too Many Requests. Common algorithms are token bucket (allows short bursts, the usual default), leaky bucket, fixed window counter, sliding window log and sliding window counter. In a distributed system the counters live in a shared store such as Redis and are updated atomically. Decide where it runs (API gateway or each service), what the key is (user, API key, IP) and whether it fails open or closed if Redis is down. We cover all of this in Designing a Rate Limiter.

What is idempotency and why does it matter in system design?

An operation is idempotent if doing it twice has the same effect as doing it once. Networks time out and clients retry, queues redeliver, and webhooks arrive twice, so any operation with side effects must tolerate repeats. In HTTP, GET, PUT and DELETE are defined as idempotent; POST is not.

The standard technique is an idempotency key: the client sends a unique key with the request, the server stores the key with the result in the same transaction as the side effect (a unique constraint does the hard work), and a repeat with the same key returns the stored result instead of charging the card again. Bring this up yourself in any design that touches money, orders or notifications.

15 system design interview questions to practice

These are the problems that come up again and again. For each one, here are the two or three ideas the question is really testing. If you can explain these confidently, the rest of the design usually follows from the framework.

1. Design a URL shortener (TinyURL)

• Generate short, unique codes: a counter encoded in base62 (7 characters give about 3.5 trillion codes) handed out in ranges, versus hashing the long URL and handling collisions.
• It is extremely read-heavy, so cache hot codes and keep the redirect path tiny.
• 301 versus 302 redirects: cacheability against analytics.

Full walkthrough: Design a URL shortener, step by step.

2. Design a rate limiter

• Token bucket versus sliding window, and what each allows in bursts.
• Atomic counters in Redis shared by all instances, with expiry.
• Placement (gateway or service), response headers, and fail-open versus fail-closed.

3. Design a unique ID generator

• Snowflake-style 64-bit IDs: timestamp, machine id and a per-millisecond sequence, so machines never coordinate per ID.
• Clock skew: what happens if a machine's clock moves backwards.
• Alternatives: database sequences handed out in blocks, and UUIDv7 (time-ordered UUIDs defined in RFC 9562), which index far better than random UUIDv4.

4. Design a distributed key-value store

• Partition with consistent hashing and replicate each key to N nodes.
• Quorums: with N replicas, reading R and writing W where R + W > N gives you overlap, so reads see the latest acknowledged write.
• Repairing divergence: hinted handoff, read repair and anti-entropy with Merkle trees.

5. Design a chat application (WhatsApp)

• Persistent WebSocket connections, plus a registry of which gateway server holds each user's connection.
• Messages stored per conversation and ordered by a per-conversation sequence number, not wall-clock time.
• Offline users: store and forward, push notifications, and delivered/read receipts as their own small messages.

6. Design a notification system

• One queue per channel (push, SMS, email) with workers calling the providers, so a slow SMS provider does not block push.
• Retries with exponential backoff, a dead-letter queue, and an idempotency key so a retry never sends twice.
• User preferences, quiet hours and per-user rate limits, checked before sending.

7. Design a news feed (Twitter / Instagram timeline)

• Fan-out on write (push a post into every follower's precomputed feed) versus fan-out on read (merge followees' posts at read time).
• The hybrid answer: push for normal users, pull for accounts with millions of followers.
• Feed storage in a cache as a capped list of post ids, then hydrate posts in batch.

8. Design search autocomplete (typeahead)

• A trie where each prefix node stores its precomputed top-k completions, so a lookup is one walk, not a search.
• Build the counts offline from query logs and refresh periodically, rather than updating on every keystroke.
• Latency tricks: debounce on the client, cache popular prefixes close to users, shard by prefix.

9. Design a web crawler

• A URL frontier with per-host queues, so you are polite to each site (and respect robots.txt).
• Deduplication of URLs (normalization plus a seen-set or Bloom filter) and of content (hash of the page).
• Distributed fetchers, DNS caching, and handling traps such as infinite calendars.

10. Design file storage and sync (Dropbox / Google Drive)

• Split files into chunks identified by a content hash: only changed chunks are uploaded, and identical chunks are stored once.
• Metadata (files, versions, chunk lists) in a database; bytes in object storage, uploaded directly with pre-signed URLs.
• Sync via change notifications to other devices, and a conflict policy (keep both copies) for offline edits.

11. Design a video streaming service (YouTube)

• Upload, then transcode asynchronously into several resolutions and bitrates, cut into short segments.
• Adaptive bitrate streaming (HLS or DASH): the player picks the segment quality that fits current bandwidth.
• The CDN serves almost all video bytes; your servers handle metadata, search and recommendations.

12. Design a ride-sharing service (Uber / Ola)

• Drivers send location every few seconds into an in-memory geospatial index (geohash, quadtree or H3 cells).
• Matching: search nearby cells, rank candidates by estimated arrival time, and offer the ride to one driver at a time with a timeout.
• The trip as a state machine (requested, accepted, started, completed, paid) persisted in a durable database.

13. Design a movie ticket booking system (BookMyShow)

• Prevent double booking: hold seats for a few minutes with an expiry, and confirm with a conditional update or unique constraint on (show, seat).
• Payment between hold and confirm, with what happens when payment succeeds after the hold expired.
• Flash-sale traffic: a virtual waiting room and rate limiting in front of the booking service.

14. Design a payment system

• Idempotency keys on every payment request, so a retry never charges twice.
• A double-entry ledger that is append-only, plus a payment state machine.
• Asynchronous confirmation through provider webhooks (which can arrive late or twice) and daily reconciliation against provider reports.

15. Design a real-time leaderboard

• Redis sorted sets: ZINCRBY to update a score, ZRANGE ... REV for the top N and ZREVRANK for a player's rank, each O(log n) plus the entries returned.
• Very large boards: shard by game or region, and show approximate ranks for players far from the top.
• Durability: the database is the source of truth; the sorted set can be rebuilt from it.

Mistakes that cost candidates the offer

• Designing before scoping. Drawing Kafka in minute two, before knowing the scale, signals pattern-matching rather than thinking.
• Estimates that lead nowhere. Five minutes of arithmetic that never changes a decision. Always finish with "so this means...".
• No trade-offs. Every choice costs something. If you cannot say what your choice costs, the interviewer assumes you do not know.
• Going silent. The interviewer can only score what they hear. Think out loud, even when you are unsure.
• Ignoring failure. What happens when the cache is cold, the primary fails, or a message is delivered twice?
• Over-engineering. Twenty microservices for a system with 50 writes a second. Start simple and scale the part the numbers say will hurt.
• Fighting the interviewer. When they push back, they are usually offering a hint. Explore it before defending your first idea.

A four-week practice plan

If you have an interview in a month, this plan fits around a job at about an hour a day.

• Week 1, building blocks: go through the concepts above until you can explain each in two minutes without notes. Memorize the estimation numbers. Run the consistent hashing program above and change the number of virtual nodes.
• Week 2, the classics: design problems 1 to 6 on paper using the 7 steps, with a 45-minute timer. Compare your answer with a worked solution afterwards and note what you missed.
• Week 3, the harder ones: problems 7 to 15. For each, write down the one deep dive you would offer and two alternatives for it.
• Week 4, mock interviews: do at least three mocks with a friend or colleague who interrupts you. Practice the wrap-up: a three-sentence summary and "what breaks at 10x".

Practice with the full question bank

If you want worked solutions to check yourself against, these TechTriber guides go further than a blog post can:

• System Design Interview: 20 Classic Problems with Solutions: 20 problems solved step by step, with requirements, estimates with the arithmetic shown, API and data model, architecture, a deep dive and failure modes, plus traps and follow-ups.
• Microservices Patterns: 60 Scenario Interview Questions: service boundaries, sync versus async, sagas and the outbox pattern, retries and circuit breakers, tracing, safe deploys and duplicate payments.
• Redis and Caching Interview Questions: 50 answers on cache-aside, stampede and penetration, Spring Cache, Spring Data Redis, locks, rate limiters, persistence and Redis Cluster.

Related reading

• System design: design a URL shortener (TinyURL) step by step, the framework applied to a full problem.
• System design: designing a rate limiter, with the algorithms compared.
• Low-level design interview in Java, for the class-design round.

FAQ

How long is a system design interview?

Usually 45 to 60 minutes, sometimes with a few minutes of introductions at the start. Use the same 7 steps either way; in a 60-minute round, give the extra time to deep dives rather than to requirements.

Do freshers get system design interview questions?

Sometimes, usually in a lighter form: explain a load balancer or a cache, or sketch a simple design such as a URL shortener with help. Many fresher rounds focus on low-level design and object-oriented modeling instead. Learning the building blocks in this guide covers both cases.

What is the difference between high level design and low level design?

High level design (HLD) is about components, data flow, storage, scaling and trade-offs across a whole system. Low level design (LLD) is about classes, interfaces, design patterns and code structure inside one component, for example a parking lot or an LRU cache in Java.

Do I need to memorize latency numbers for system design?

Only the orders of magnitude: memory is about 100 ns, SSD about 100 µs, a same data center round trip about 0.5 ms and a cross-continent round trip about 150 ms. What matters is the ratios, for example that a network call costs thousands of memory reads.

How many system design problems should I practice before an interview?

Ten to fifteen problems done properly, with a timer and a written answer, are worth more than fifty read passively. The 15 in this guide cover most of the patterns you will meet: ID generation, caching, fan-out, real-time connections, geospatial search, booking and payments.