Depth vs Breadth in System Design: Knowing What to Explore

The Deep Dive That Landed a Staff Offer

Designing a rate limiter, a candidate covered the full architecture in 15 minutes: API gateway, token bucket, Redis, monitoring. Solid but standard. Then the interviewer asked, 'What happens when Redis goes down?' Most candidates panic. This candidate said: 'There are three options. One: fail open and allow all traffic, risking overload. Two: fail closed and reject all traffic, causing an outage. Three: fall back to a local in-memory rate limiter with degraded accuracy. For a payment API, I'd fail closed. For a social feed API, I'd fail open. For most services, option three.' That single deep dive showed architect-level thinking and earned a Staff offer.

Reading Interviewer Signals

Depth Signals From the Interviewer:

Signal                           What It Means
-----------------------------    ----------------------------
'Tell me more about X'          GO DEEP on X immediately
'That's interesting'             They want depth here
Leaning forward, eye contact     Keep going, you're on track
'What about Y?'                  Concern about 'Y', address it
'How would that work at scale?'  They want you to find the flaw
'Let's move on to another area'  STOP depth, go back to breadth
Glancing at clock                You're spending too long here

When YOU Choose What to Deep Dive:

Pick the hardest constraint - the part where naive approaches break:
  URL Shortener   -> Hash collisions + redirect latency
  Twitter Feed    -> Celebrity fanout (50M followers)
  Chat System     -> Message ordering + delivery guarantees
  Rate Limiter    -> Distributed state + failure modes
  Payment System  -> Exactly-once processing + idempotency

Depth Reveals Seniority

What Your Depth Level Signals:

Level       Typical Depth Focus          Example
---------   -------------------------    -------------------
Junior      Implementation details       'I'd use a HashMap
(L3-L4)     Code structure, SQL          with chaining for
            queries, data types          collision handling'

Senior      Distributed systems          'At 100K req/sec we
(L5)        trade-offs, scalability      need sharded rate
            patterns, failure modes      limiters with eventual
                                         consistency across shards'

Staff+      Organizational impact,       'This migration requires
(L6+)       migration strategy,          a 6-month strangler fig
            operational complexity,      approach. I'd have the
            team ownership boundaries   platform team own the
                                         gateway while product
                                         teams migrate services'

Interview Tip

Always start with breadth (show you see the whole system), then go deep on the hardest constraint. The hardest constraint is where naive approaches break at scale - that's what the interviewer wants to hear about. When the interviewer gives you a choice, pick the most technically interesting problem, not the easiest one. And watch for signals: 'tell me more' means go deeper, 'let's move on' means you've been too deep for too long.

<

/blockquote>