Deep Dives

After presenting your high-level design, interviewers will probe specific areas in depth. These deep dives separate good candidates from great ones. They reveal whether you truly understand distributed systems or are just drawing boxes.

What Are Deep Dives?

Deep dives are focused technical discussions on specific aspects of your design. The interviewer might ask:

• "How exactly would you implement the timeline fanout?"
• "Walk me through what happens when this database fails"
• "How do you ensure messages aren't lost in the queue?"
• "What's your sharding strategy?"

Common Deep Dive Topics

Prepare for these areas as they come up in almost every interview:

Level-Based Expectations: Deep Dives

What depth is expected at each level:

Deep Dive #1: Database Sharding

One of the most common deep dive topics. Be ready to discuss:

Sharding Strategies

Key Questions to Answer

• What's the shard key? Choose based on your access patterns
• How do you handle hot shards? Splitting, caching, or repartitioning
• What about cross-shard queries? Scatter-gather or denormalization
• How do you add new shards? Consistent hashing or rebalancing strategy

Deep Dive #2: Caching Strategies

Caching is critical for performance. Know these patterns:

Cache-Aside (Lazy Loading)

Read:  App checks cache → miss → read DB → populate cache → return
Write: App writes to DB → invalidate/delete cache entry

Trade-offs:

• ✅ Only caches what's actually needed
• ❌ First request is always slow (cache miss)
• ❌ Cache and DB can become inconsistent

Write-Through

Write: App writes to cache → cache writes to DB → return
Read:  Always read from cache

Trade-offs:

• ✅ Cache always consistent with DB
• ❌ Write latency increases
• ❌ May cache data that's never read

Write-Behind (Write-Back)

Write: App writes to cache → return immediately
       Background: cache asynchronously writes to DB

Trade-offs:

• ✅ Fastest write performance
• ❌ Risk of data loss if cache fails before persistence
• ❌ Complex consistency model

Cache Invalidation

The two hard problems in computer science: cache invalidation and naming things.

Deep Dive #3: Consistency and Availability

The CAP theorem is fundamental. Be ready to discuss:

Strong vs. Eventual Consistency

Handling Conflicts

In eventually consistent systems, conflicts happen. Resolution strategies:

• Last-write-wins (LWW): Simple but can lose data
• Vector clocks: Track causality, detect conflicts
• Application-level merge: Custom logic (e.g., CRDTs for collaborative editing)

Deep Dive #4: Failure Handling

Distributed systems fail. Show you've thought about this:

Retry Strategies

# Exponential backoff with jitter
retry_delay = min(base_delay * (2 ^ attempt) + random_jitter, max_delay)

Key considerations:

• Idempotency: Is it safe to retry?
• Timeout: How long to wait?
• Max retries: When to give up?
• Circuit breaker: When to stop trying altogether?

Circuit Breaker Pattern

Prevent cascade failures:

State: CLOSED → OPEN → HALF-OPEN → CLOSED

CLOSED:  Requests flow normally, failures counted
         If failures exceed threshold → OPEN

OPEN:    Requests fail immediately (fast failure)
         After timeout → HALF-OPEN

HALF-OPEN: Allow one request through
           If succeeds → CLOSED
           If fails → OPEN

Graceful Degradation

When a dependency fails, degrade gracefully:

Deep Dive #5: Rate Limiting

Protect your system from abuse and overload:

Algorithms

Distributed Rate Limiting

Challenge: Rate limits across multiple servers.

Approaches:

1. Centralized counter (Redis): Accurate but adds latency
2. Local counters with sync: Fast but can over-allow
3. Sticky sessions: Route user to same server, local counting

Client → Load Balancer → API Server → Redis (rate limit check) → Backend

def is_allowed(user_id: str) -> bool:
    key = f"rate_limit:{user_id}"
    now = time.time()

    # Use Redis transaction
    with redis.pipeline() as pipe:
        # Get current bucket state
        pipe.hgetall(key)
        # Execute and get result
        result = pipe.execute()[0]

        tokens = float(result.get('tokens', 100))
        last_update = float(result.get('last_update', now))

        # Refill tokens based on time elapsed
        elapsed = now - last_update
        tokens = min(100, tokens + elapsed * (100/60))  # 100 tokens per 60 sec

        if tokens >= 1:
            # Consume token
            tokens -= 1
            pipe.hset(key, mapping={'tokens': tokens, 'last_update': now})
            pipe.expire(key, 120)  # Cleanup
            pipe.execute()
            return True
        else:
            return False

How to Handle Deep Dives You Don't Know

You won't know everything. Here's how to handle gaps:

Be Honest

"I haven't implemented this specific pattern before, but here's how I'd approach it..."

Reason from First Principles

"I'm not sure of the exact algorithm, but the problem we're solving is X, so the solution likely needs to handle Y and Z..."

Ask Clarifying Questions

"To make sure I'm focusing on the right aspect, are you more interested in the consistency guarantees or the performance characteristics?"

Common Deep Dive Mistakes

1. Going Too Deep Too Early

Don't spend 10 minutes on one component before finishing the high-level design.

2. Not Adapting to Feedback

If the interviewer looks confused or tries to redirect, pivot quickly.

3. Memorized Answers Without Understanding

Interviewers can tell when you've memorized something. Be ready for follow-up "why" questions.

4. Ignoring Trade-offs

Every technical decision has trade-offs. Acknowledge them proactively:

"This approach gives us strong consistency but increases latency. Given our requirements, I think that's the right trade-off because..."

Putting It All Together

A successful deep dive looks like this:

Interviewer: "How would you handle the case where a celebrity with 10 million followers posts a tweet?"

You: "Great question. This is the hot follower problem. If we fan out on write, a single tweet would trigger 10 million timeline updates, which would be too slow.

I'd use a hybrid approach: for regular users, we continue fan-out on write for fast reads. For celebrities, we mark them as 'high-follower' accounts and use fan-out on read instead.

When a user fetches their timeline, we merge two sources: their pre-computed timeline cache, plus a live query of recent tweets from any celebrities they follow.

The trade-off is more complex read path, but it avoids the write amplification problem. We'd monitor the threshold for what counts as 'high-follower' and tune it based on system performance."

What's Next

You now have a framework for requirements, entities/APIs, high-level design, and deep dives. The next step is practice. Work through real problems, get feedback, and iterate.