Intermediate 13 min read How to answer

Driving deep dives and trade-offs

In one line

Pick the hardest one or two problems in your design, lay out two or three real options, compare them on the requirements with numbers, choose one, and say what you gave up and how it fails.

What it is

A deep dive is where you zoom into one component or one problem and solve it properly: how exactly the feed is built, how double booking is prevented, how a hot key is handled, how payments stay exactly-once from the user's point of view. It typically takes 15 to 20 minutes, the largest part of the interview.

A trade-off is a decision where every option has a cost. Strong candidates do not say 'use Kafka' or 'use Cassandra'; they say 'option A gives X but costs Y; option B the reverse; given our requirement Z, A is better, and if Z changed we would switch.'

Choosing what to deep-dive is itself a signal. The right topics come from your estimates and requirements: the highest-volume path, the strongest consistency need, or the most likely failure. If the interviewer points somewhere, go there.

Why interviewers ask

Depth is the signal that most separates SDE-2 from SDE-3 and above. A broad but shallow design shows you know the vocabulary; a deep dive shows you could build and run it. Interviewers write down specific evidence from this part, such as 'explained fan-out on write vs read with the celebrity case and chose a hybrid', and that evidence carries the hiring decision.

How it works

1Choose the topic: look at your estimates and requirements and name the hardest part. Say it: 'The two hard parts here are inventory under flash-sale load and payment consistency. I will start with inventory.' Ask if the interviewer agrees.
2State the problem precisely with numbers: '1 lakh users try to buy 10,000 units of one phone in the first 60 seconds; we must never oversell and the page must stay up.'
3Lay out two or three real options, starting with the simplest that could work. Avoid straw men; each option should be something a real team would pick.
4Compare on the criteria that matter for this requirement: correctness, latency, throughput, cost, operational complexity, failure behaviour. A small table on the whiteboard helps.
5Choose and justify in one sentence, tied to a requirement or number.
6Walk through the chosen option in detail: data structures, keys, the exact sequence of operations, what is atomic, timeouts and retries.
7Cover failure modes of the chosen option: what if this node, cache or consumer dies mid-operation? How is state recovered or reconciled?
8Close with what you gave up and when you would revisit: 'If we had 100x the SKUs with flat demand, the simpler database approach would be enough.'

Worked example · Deep dive: flash-sale inventory for a popular phone

Problem: 10,000 units, about 1 lakh (100,000) buyers in the first minute, peak about 20,000 add-to-cart or buy attempts per second on one SKU. No overselling.
Option A, database row with conditional decrement: UPDATE stock SET qty = qty - 1 WHERE sku = ? AND qty > 0. Correct and simple, but every attempt locks the same row; one hot row in Postgres manages perhaps a few thousand such updates per second, so requests queue and time out.
Option B, atomic counter in Redis: DECR on the SKU key, or a Lua script that checks and decrements. One Redis shard can handle tens of thousands of ops per second on one key. Fast, but Redis is not the system of record and could lose recent writes on failover.
Option C, a queue in front: accept purchase intents into Kafka, partitioned by SKU, and a single consumer per SKU allocates stock in order. Fair and smooth, but users wait for a result asynchronously.
Choice: B for admission plus the database as truth. Redis decides who gets a reservation token quickly; the reservation is then written to the database with an expiry of 10 minutes for payment. If payment fails or expires, stock is released.
Failure: if Redis fails over and loses a few decrements, we could hand out a few extra tokens. Protect with the database constraint at order creation (qty cannot go below zero) and reconcile Redis from the database every few seconds during the sale.
Trade-off stated: we accept a small chance that a user with a token fails at order creation, in exchange for keeping the database load to roughly 10,000 successful writes instead of 1 lakh+ attempts.

Picture it

It is like a doctor examining a patient. A quick look over the whole body comes first, but the diagnosis comes from going deep on the one symptom that matters, ordering the right tests, weighing treatment options and explaining the side effects of the chosen one.

Reference code

-- Redis Lua script: reserve one unit atomically
-- KEYS[1] = stock:{sku}, ARGV[1] = quantity requested
local left = tonumber(redis.call('GET', KEYS[1]) or '0')
local want = tonumber(ARGV[1])
if left >= want then
  redis.call('DECRBY', KEYS[1], want)
  return 1   -- reserved; caller then writes the reservation to the DB
end
return 0     -- sold out

Key patterns

Options table

When: Comparing approaches

How: Rows are options, columns are the two to four criteria that matter (correctness, p99 latency, throughput, ops cost). Fill with short words or numbers. It makes the choice obvious and visible.

Choose, then attack your choice

When: After picking an option

How: Ask yourself 'how does this break?' before the interviewer does: node failure, retry storms, hot keys, clock skew, partial failure between two writes.

Name the revisit trigger

When: Ending a deep dive

How: State the condition under which you would switch: 'If writes pass about 20k per second we move from a single Postgres primary to sharding by merchant_id.'

Real-world use

Twitter's hybrid timeline fan-out

Twitter precomputed home timelines by pushing tweets into followers' cached timelines, but merged tweets from accounts with very large follower counts at read time. A classic trade-off between write cost and read latency, resolved with a hybrid.

Flipkart Big Billion Days

Large Indian e-commerce sales concentrate demand on a few deals in the first minutes. Teams prepare with load tests, inventory reservation strategies and graceful degradation of non-critical features, which is the same deep dive as the example above.

Amazon's Dynamo paper

The 2007 Dynamo paper is a model of explicit trade-offs: it chose availability and 'always writable' carts over strong consistency, and explained conflict resolution and quorum tuning as the cost.

In a project

Your team must decide how to send booking confirmation to a partner hotel system that is slow (p99 4 seconds) and sometimes down for minutes.

Name the requirement: the user must see 'booking confirmed' quickly, and the hotel must eventually receive the booking exactly once in effect.
Option 1: call the hotel synchronously in the booking request. Simple, but user latency and availability depend on the hotel.
Option 2: save the booking and an outbox event in one transaction, then a worker delivers to the hotel with retries and an idempotency key.
Option 3: a durable workflow engine such as Temporal that runs the booking saga with timers and compensation if the hotel rejects.
Choose Option 2 for one partner today because it is simplest to operate; note that Option 3 becomes worth it when there are multi-step flows with compensation (payment refund if the hotel rejects).
Write the decision record with the options, the choice, the reason and the trigger to revisit.

Impact: User-facing latency no longer depends on the partner, partner outages delay delivery instead of failing bookings, and the team has a clear rule for when to adopt a workflow engine.

Trade-offs

Use it when

After the high-level design is complete and agreed
When the interviewer asks 'how exactly would this work?'
When your estimates point to a clear bottleneck

Avoid it when

Before there is a complete end-to-end design
Diving into an easy area, such as login, while ignoring the actual hard problem
Going so deep into one area that failure handling and wrap-up are never reached

Common mistakes

Picking a deep-dive topic that is easy and safe rather than the real bottleneck.
Offering only one option, so there is no trade-off to discuss.
Straw-man options that nobody would choose.
Choosing without linking to a requirement or a number.
Ignoring failure modes of the chosen option.
Saying 'exactly-once' without explaining idempotency or deduplication behind it.
Refusing to change a choice when the interviewer adds a new constraint.

Interview questions

Quick revision

Pick the topic from estimates and requirements; confirm with the interviewer.
State the problem with numbers.
Two or three real options, simplest first.
Compare on correctness, latency, throughput, cost, operations.
Choose with a one-line reason tied to a requirement.
Detail the chosen option: keys, sequence, what is atomic.
Attack your own choice: failures and recovery.
End with what you gave up and the trigger to revisit.
Spend 15 to 20 minutes here; this is where levels are decided.

Check yourself

1. How should you choose what to deep-dive?

2. What makes a trade-off discussion strong?

3. In the flash-sale example, why is the database still involved after Redis admits a buyer?

4. Which sentence best closes a deep dive?

Saved on this device. Create a free account to keep it on every device.

Drawing the high-level design What impresses interviewers (and red flags)

Practise this with Sam

A real mock interview, out loud, with an honest scorecard. Free to start.

Start free