Tracks · SDE-2
SDE-2 system design
This track is about the part of the round where the easy answer stops working. Your database is too big for one machine, a server dies in the middle of a payment, and a message arrives twice. You learn how data is copied and split, how systems fail safely, and how queues and events work. Then you study real designs: payments, tickets, chat and a news feed.
- 51steps in 6 stages
- 17 hin total, plus incident time (it varies)
- 5 weeksat 4 hours a week
Start here if you know the basics and your answers stop when the interviewer asks “what if it fails?”.
Do the SDE-1 track first if you cannot yet explain an index, a cache or a load balancer.
The track has 26 lessons, 9 trade-offs, 16 practice steps. Steps marked “Free account” are inside the app.
Stage 1 of 6 · 3 h 26 min
Copies and splits of data
You can explain replication and sharding, what goes wrong with each, and how to choose a shard key.
- 24 min
Lesson
Replication: leader and followers
How a database keeps copies of its data on other servers, what the copies are for, and what happens when the leader waits for them or does not.
- 24 min
Lesson
Why do I see old data after saving? (replica lag)
Why a follower can show old data right after you save, how long the delay lasts, how to make users see their own changes, and the first plain meaning of eventual.
- 13 min
Trade-off
Replication vs sharding
When to copy a database with replicas and when to split it with shards, the numbers that decide, and what each choice breaks and costs.
- 24 min
Lesson
Failover: what happens to writes in flight
What happens when the leader dies: how a follower is promoted, which writes can be lost, how long writes stop, and how two leaders at once do harm.
- 24 min
Lesson
Sharding: splitting data across servers
How to split one database over several servers: the shard key, range, hash and directory, what a bad key costs, and why adding a shard is hard.
- 15 min
Trade-off
Hash vs range vs directory sharding
How to choose hash, range or directory sharding for your shard key, the numbers that change the answer, and what breaks when the data grows.
- 7 min
DrillFree account
The newest shard is always overloaded
Practise this decision: how to choose the shard key. Seven minutes.
- 24 min
Lesson
Adding servers without moving all the data (consistent hashing)
How a ring of hash positions lets you add or remove a server and move only a small share of the data, and how virtual nodes make the load even.
- 21 min
Lesson
When one key gets all the traffic (hot partition)
Why one very popular key can overload one shard whatever the number of shards, how to find it, and how to split it, copy it or cache it.
- 15 min
SimulatorFree account
Simulator Level 4: add read replicas
Add read replicas and see replication lag with the numbers shown.
- 15 min
SimulatorFree account
Simulator Level 5: shard the database
Shard the database, pick a shard key, and handle a hot shard.
Stage 2 of 6 · 1 h 25 min
Consistency
You can say what the user sees when data is old, and which choice you give up.
- 24 min
Lesson
CAP and consistency levels: what you give up when the network breaks
The levels of consistency from strong to eventual, what a network partition is, what the CAP theorem really says, and the cost in milliseconds that PACELC adds for normal times.
- 15 min
Trade-off
Strong vs eventual vs causal consistency
How to choose strong, causal or eventual consistency for each operation, the numbers that change the answer, and what breaks with each.
- 15 min
Trade-off
Synchronous vs asynchronous replication
When to make a database wait for its copies before it says saved, the numbers that change the answer, and what breaks with each choice.
- 7 min
DrillFree account
Can we lose confirmed orders when the leader dies?
Practise this decision: wait for the copy or do not wait. Seven minutes.
- 24 min
Lesson
Whose clock is right? Putting events in order
Why two servers never agree on the time, why sorting by timestamp can put a reply before its question, and how per-key sequence numbers and logical clocks give a safe order.
Stage 3 of 6 · 2 h 8 min
Fail safely
You can retry without making things worse, and protect a service from too many requests.
- 24 min
Lesson
Timeouts, retries, backoff and jitter
How to set a time limit on every call, when to try again, how long to wait between tries, and how retries can turn a small problem into a storm.
- 13 min
Trade-off
Retry vs fail fast
When to retry a failed call and when to fail fast and return an error or a fallback, the numbers that decide, and what breaks with each.
- 7 min
DrillFree account
A payment status service is flooded on salary day
Practise this decision: retry the call or fail fast. Seven minutes.
- 12 min
Lesson
Stop calling a broken service (circuit breaker, bulkhead)
How a circuit breaker stops calls to a service that is failing, how a bulkhead gives each service its own workers, and why one slow service must not use all of them.
- 24 min
Lesson
Rate limiting: token bucket, leaky bucket, sliding window
How to limit the requests one user can send, with five counting methods (fixed window, sliding window log, sliding window counter, token bucket, leaky bucket) and what each one costs.
- 13 min
Trade-off
Token bucket vs sliding window rate limiting
Which rate limiting method to choose: token bucket or sliding window. The numbers that decide, the bursts each one allows, and what breaks.
- 7 min
DrillFree account
A rate limit must allow the burst of an app screen
Practise this decision: token bucket or sliding window. Seven minutes.
- 28 min
Lesson
Case study: Rate limiter for many servers
How to make a rate limit hold when a client's requests reach many servers: shared counters in Redis, atomic steps, speed and size, quotas, and what an attacker does.
Stage 4 of 6 · 2 h 42 min
Queues and events
You know when to use a queue, what “once, twice or never” means, and how to make a repeat safe.
- 23 min
Lesson
Queues: what they solve, and what must stay in the request
How a queue moves slow work out of the user's request, how to choose what moves and what stays, and how to do the arithmetic for a growing backlog.
- 24 min
Lesson
Queue, log or pub/sub (RabbitMQ-style vs Kafka-style)
The difference between a queue that removes messages and a log that keeps them, with partitions, offsets and consumer groups, event-driven design, and how to choose.
- 12 min
Trade-off
Queue vs pub/sub vs log
Which message system to choose: a queue, publish and subscribe, or a log. The numbers that change the answer and what breaks with each.
- 20 min
Lesson
Will my message arrive once, twice or never?
Why a message can be lost or repeated, what at-most-once, at-least-once and exactly-once mean, and how the order of the acknowledgement and the work decides which one you get.
- 24 min
Lesson
Doing it twice should be safe (idempotency)
How to make a request or a message safe to receive twice: idempotency keys, a table of seen IDs with a unique constraint, and consumers that skip repeats.
- 15 min
Trade-off
At-least-once with idempotency vs exactly-once
How to choose between at-least-once delivery with idempotent handlers and a broker's exactly-once features, the numbers behind it, and what breaks.
- 20 min
Lesson
When too much arrives: slow down, say no, or do less
What to do when more work arrives than a service can finish: bounded queues and back-pressure, load shedding by priority, and graceful degradation, with the numbers.
- 24 min
Lesson
Save and announce together (outbox, CDC)
Why saving to a database and sending a message are two separate writes that can disagree, and how an outbox table or change data capture makes them agree.
Stage 5 of 6 · 3 h 53 min
Real systems
You have seen how payments, bookings, chat and feeds are put together, and why.
- 24 min
Lesson
Many steps, one undo plan (sagas)
How to finish a job that spans several services when one database transaction cannot cover it: steps with compensations, who runs the plan, and why two-phase commit is rare.
- 24 min
Lesson
Ledgers and reconciliation
How to keep money records that can always be explained: an append-only ledger with balanced entries, payments that stay pending until confirmed, and a daily check against the gateway's report.
- 28 min
Lesson
Case study: Payment system (UPI, cards; wallet twist)
How to design the payment part of an app: one key for each payment, a state machine, safe callbacks, a ledger, an outbox, a daily check against the gateway, and a wallet version.
- 28 min
Lesson
Case study: Ticket booking
How to design ticket booking for trains and cinemas: seat states, a hold that expires, a waiting room for the 10 am rush, payments that finish late, and a version for hotel rooms.
- 23 min
Lesson
Polling, long polling, SSE and WebSockets
Four ways to send news from a server to a phone (polling, long polling, Server-Sent Events and WebSockets), using a live cricket score, and what an open connection costs.
- 23 min
Lesson
A feed for 10 million followers: build early or on demand (fan-out)
Two ways to build a home feed (push posts into follower lists, or merge on each read) and the hybrid for accounts with millions of followers.
- 14 min
Trade-off
Fan-out on write vs fan-out on read
How to choose between building each follower's feed when a post is made or when the feed is opened, the numbers that decide it, and what breaks.
- 15 min
SimulatorFree account
Simulator Level 6: build the home timeline
Build the home timeline. Push or pull, and what the celebrity does to your servers.
- 26 min
Lesson
Case study: Chat (WhatsApp)
How to design a chat app: connection servers, a store-first message path, order inside each chat, receipts, offline messages and presence, with the numbers.
- 28 min
Lesson
Case study: News feed
How to design the home feed of a social app: the path of a post and of a feed open, a hybrid timeline, a ranking step that can be switched off, photos on a CDN and the caches, with the numbers.
Stage 6 of 6 · 3 h 28 min, plus incident time
Practise under pressure
You have answered real situations with a clock, and you have done four full mock interviews.
- 7 min
- 7 min
DrillFree account
Charged customers with missing or double orders
A failover loses writes. Seven minutes.
- 7 min
- 7 min
DrillFree account
1,200 users have extra wallet money
The same message was handled twice. Seven minutes.
- Time varies
IncidentFree account
Incident investigation
An alert fires. Find the cause from the evidence and explain what you would do.
- 45 min
Design mockFree account
Design a Notification System
A mock interview about queues, retries and fan-out.
- 45 min
Design mockFree account
Design a Photo Sharing App
A mock about a feed of photos, a CDN and one photo that gets all the likes.
- 45 min
Design mockFree account
Design a Hotel Booking System
A hard mock about rooms that must not be sold twice, between a search list and a booking.
- 45 min
Design mockCheckpointFree account
Design a Ticket Booking System (Movies and Trains)
Your checkpoint: a hard mock about 200,000 people and 1,000 seats.
Estimates
How the time is counted
These times are planning estimates, not deadlines. Yours will vary.
- Lessons and trade-off pages: the number of words divided by 130, rounded, plus 4 minutes to think.
- A Drill: about 7 minutes. A system design mock: allow about 45 minutes. A machine coding mock: allow about 75 minutes.
- Other mocks: a SQL mock with one problem, about 29 minutes. A behavioural mock, about 36 minutes. A resume mock, about 35 minutes. A coding mock, about 45 minutes.
- A simulator level or a Cost Lab workload: allow about 15 minutes. This is our own estimate for a first try. It can take you less or more.
- Incident investigation: time varies. The room has a simulated clock; your real time depends on how you investigate. It has no fixed time, so it is not counted in any total.
- The total is the sum of all steps that have a time. The weeks are the hours divided by 4, rounded up. We assume 4 hours a week, like a person with a job. Doing a step again is not counted.
Ready for the checkpoint?
The last step is a mock interview with an AI interviewer. It gives you a report that shows what you did well and what was missing.