Motivation

A candidate sits down for the system design round. The interviewer says 'Design Twitter'. The candidate's mind goes blank, then races: where to start? Database? Caching? News feed algorithm? They start drawing boxes and arrows; ten minutes in, they realize they never asked whether this is for 1 million or 1 billion users, never agreed on what 'Twitter' means in this interview, never wrote a single API. The interviewer is patient but visibly disappointed. By minute 30 the candidate is deep in news-feed fan-out details and has not addressed scale, storage, or trade-offs. They run out of time without a coherent design.

This is the most common failure mode. The candidate is technically capable; they just lacked structure. With structure, the same person produces a clear, defensible design and signals exactly the kind of thinking interviewers grade.

The RESHADED framework (Requirements, Estimation, Schema / API, High-level design, Architecture deep dive, Edge cases, Done) is one of several common structures that work. It is widely used because it maps to how senior engineers actually approach novel problems: clarify scope, ground in numbers, design the contract, sketch the system, deepen the critical parts, surface what could go wrong, summarize. Other names exist (4S, RADIO, STAR-for-design); the steps converge.

Why this matters: structure is not a substitute for technical knowledge. It is what lets your technical knowledge land. A candidate with deep knowledge and no structure looks unfocused; a candidate with the same knowledge and a clear framework looks senior.

Deep Dive

The framework at a glance

+----------+----------+----------+----------+----------+----------+----------+
|    R     |    E     |  S / A   |    H     |    A     |    E     |    D     |
| Require- | Estimate | Schema / |  HLD     | Arch.    | Edge     | Done /   |
| ments    |          |  API     |          | deep     | cases    | wrap-up  |
|          |          |          |          | dive     |          |          |
|  ~5 min  |  ~3 min  |  ~5 min  |  ~5 min  | ~20 min  |  ~5 min  |  ~2 min  |
+----------+----------+----------+----------+----------+----------+----------+

Rough time budget for a 45-minute interview. The deep dive is the longest stage because it is where the senior signal lives.

Stage R: Requirements (5 minutes)

The goal: agree with the interviewer on what 'design X' means in this interview. Without alignment you will design the wrong system.

Ask three categories of question:

Functional requirements ('what should the system do?'):

• 'What are the core user actions?' Tweet, follow, view timeline.
• 'What features are out of scope?' Direct messages, payments, ads, search.
• 'What is the read / write ratio?' For Twitter-like products: 100:1 or higher; this drives caching strategy.
• 'What is the consistency requirement?' Eventual is fine for the timeline; strong is required for follower lists.

Non-functional requirements ('how should it behave?'):

• 'What scale are we targeting?' Daily active users, peak QPS, storage.
• 'What is the latency budget?' Read p99 < 200 ms, write p99 < 500 ms.
• 'What availability target?' Three nines, four nines, five nines drive very different architectures.
• 'What about durability?' Tweets cannot be lost; transient analytics events can.
• 'Geographic distribution?' Single region, multi-region, global.

Constraints ('what is fixed?'):

• 'Is this a green-field design or are we constrained by existing infra?' Affects which databases / clouds are available.
• 'Is there a team and budget?' Senior interviews often want you to consider operational cost.

Write down the answers. The list is what you defend against during deep dive: 'we agreed on eventual consistency for the timeline, so I am willing to accept a few seconds of fan-out lag'.

Avoid the trap of asking too many questions. Five minutes is the budget. If the interviewer is short on requirements, make and announce assumptions ('I'm going to assume 200M DAU and read:write of 100:1 unless you'd like to change that') and move on.

Stage E: Estimation (3 minutes)

The goal: ground the design in numbers that drive architectural choices.

The minimal estimates:

• Daily active users (DAU) -> peak QPS.
• QPS -> server count, network bandwidth.
• Storage per user / per object -> total storage, growth rate.
• Bandwidth per request -> network egress cost, CDN need.

Typical Twitter-like back-of-envelope:

DAU                         200,000,000 users
Tweets per user per day               2 tweets
Reads per user per day              100 reads
Tweet writes per day        400,000,000 tweets
Tweet reads per day      20,000,000,000 reads

Writes per second (avg)           4,600 QPS
Writes per second (peak)         14,000 QPS  (3x avg)
Reads per second (avg)          230,000 QPS
Reads per second (peak)         700,000 QPS

Tweet size                          280 bytes
Daily storage (tweets)              112 GB / day
With metadata (5x)                  560 GB / day
Five-year storage                  ~1 PB

Media per tweet (1 in 5)              1 MB
Daily media storage                  80 TB / day

Four numbers (DAU, QPS, storage, bandwidth) are enough. Do not chase precision; round aggressively. The numbers exist to drive the design ('700k QPS reads means we need a cache hit ratio above 99% or this is impossible'), not to be exact.

This is the topic of a separate lesson; here, just hit the four numbers and move on.

Stage S/A: Schema and API (5 minutes)

The goal: define the contract before drawing components. Two sub-deliverables:

API: the operations your system exposes. Two or three endpoints are usually enough.

POST   /api/tweets                    -> create tweet
GET    /api/users/{id}/timeline       -> get personalized timeline
POST   /api/users/{id}/follow/{other} -> follow user

Specify auth, request body, response shape, idempotency. This is the public face of your design; if it is wrong, everything below it is wrong.

Data model: the entities and relationships. Two or three tables are usually enough at this stage.

tweets:    (id, user_id, content, media_url, created_at)
followers: (follower_id, followee_id, created_at)
users:     (id, username, display_name, profile_url)

Decide the storage choice per entity (SQL for users / followers, key-value or wide-column for tweets at scale, blob storage for media). Do not commit to specific products yet; commit to categories.

This stage is where many candidates skip ahead to 'we'll use Cassandra'. Resist. The schema is a senior signal; rushing it shortcuts the conversation.

Stage H: High-level design (5 minutes)

The goal: a single diagram showing the data path through the major components. Five to ten boxes is the right size.

A Twitter-like HLD:

+----------+
[ Mobile / web client ] -> | CDN /    |
                           | edge     |
                           +----+-----+
                                |
                                v
                           +----+-----+
                           | API GW + |
                           | LB       |
                           +----+-----+
                                |
            +-------------------+----------------+
            |                                    |
            v                                    v
     +-------------+                      +-------------+
     | Tweet svc   |                      | Timeline    |
     | (write)     |                      | svc (read)  |
     +------+------+                      +------+------+
            |                                    |
            v                                    v
     +-------------+                      +-------------+
     | Tweet DB    |                      | Timeline    |
     | (write-     |                      | cache       |
     |  optimized) |                      | (Redis)     |
     +------+------+                      +------+------+
            |
            v
     +-------------+                      +-------------+
     | Fan-out     | -- pushes timeline-> | Timeline    |
     | service     |    entries           | cache       |
     +-------------+                      +-------------+

Draw the data path first (write path and read path), then add the control path (auth, rate limiting), then add the failure path (replication, retries) only if asked. Keep it small at this stage; deep dive is where details land.

Keep the diagram clean. Boxes labeled, arrows directional, layers stacked top-to-bottom or left-to-right consistently. If you cannot read your own diagram, neither can the interviewer.

Stage A: Architecture deep dive (20 minutes)

The goal: pick the 2-4 components that make or break the design and analyze them deeply. This is where 80% of the senior signal lives.

Picking what to deep-dive depends on the prompt:

• Twitter -> news feed fan-out (push vs pull vs hybrid), celebrity problem.
• Uber -> location indexing (Geohash / quadtree / S2), driver dispatch matching.
• Chat -> message storage + delivery semantics + presence + WebSocket connection management.
• URL shortener -> ID generation (Snowflake / hash) + read-heavy caching + analytics pipeline.
• Search -> inverted index + ranking + sharding + the indexing pipeline.

For each chosen component, structure the conversation:

1. State the design choice and the alternatives. 'For news feed I see three options: push (fan-out on write), pull (fan-out on read), or hybrid.'
2. Explain the trade-offs. 'Push gives fast reads but write amplification with celebrity accounts; pull gives no write amplification but slower reads and join cost.'
3. Pick one and justify with the agreed requirements / numbers. 'At 230k read QPS and our latency budget, I would pick hybrid: push for normal users, pull for celebrities (>1M followers).'
4. Flag the edge cases. 'The celebrity threshold needs tuning; users near the boundary will flip in and out.'

This pattern (alternatives -> trade-offs -> choice -> edge cases) is what scales the discussion. Repeat for each chosen component.

Leave room for the interviewer to redirect. They have specific things they want to discuss; if they say 'tell me about the database', drop your current branch and follow.

Stage E: Edge cases (5 minutes)

The goal: surface what could go wrong before the interviewer asks.

Standard edge cases by system class:

• Read-heavy systems: cache stampede, hot keys, cache invalidation, thundering herd on cache miss.
• Write-heavy systems: hot shards, write amplification, retry storms, queue back-pressure.
• Distributed systems: split-brain, network partition, partial failures, clock skew, exactly-once vs at-least-once.
• User-facing systems: rate limiting, abuse, DDoS, GDPR / right to erasure.
• Multi-tenant systems: noisy neighbor, cross-tenant data leakage, tenant isolation.

Name one or two from each that fit your design. 'For Twitter, the hot key on a celebrity tweet means a single Redis key gets 1M reads per second; we'd shard by tweet_id for the cache or use Redis Cluster with consistent hashing.' This kind of unprompted observation is a strong senior signal.

Also mention monitoring and operational concerns: 'I'd want a metric on fan-out lag and an alert when it exceeds 30 seconds; also a separate metric on celebrity-pull tail latency.'

Stage D: Done / wrap-up (2 minutes)

The goal: a brief summary that ties the design back to requirements.

• 'We designed for 200M DAU at 700k peak read QPS with eventual consistency on the timeline.'
• 'The key trade-offs: hybrid fan-out for the celebrity problem, write-optimized DB plus aggressive caching for reads, async media processing.'
• 'If we had more time, I'd cover: search, ML ranking, multi-region replication, the analytics pipeline.'

This last bullet is important: it shows you know what you did NOT cover, which signals scope awareness. The interviewer often asks one of those follow-ups.

Reading the interviewer

The framework is a default; the interviewer is the conductor. Some signals to watch:

• 'Tell me more about X' = they want depth there. Drop the current branch.
• 'How would this scale to 10x?' = they want to test capacity reasoning. Walk through the bottlenecks.
• 'What if a node fails?' = they want failure analysis. Walk through the recovery flow.
• 'You mentioned Y; let's discuss it' = they spotted something interesting; lean in.
• Silence + nodding = on track; keep going.
• Frowns or 'hmm' = they disagree or want you to reconsider. Pause, ask 'what concerns you about this?'
• Looking at the time = wrap up the current point and consider moving on.

The candidate who reads signals well outperforms the candidate who plows through their script regardless. The framework is the script; the signals tell you which lines to emphasize, which to skip, which to revisit.

Common interview anti-patterns

• Going straight to deep dive: 'I would use Cassandra and a Redis cache' in minute 2 with no requirements, no estimates, no API. Reads as memorized recipe, not engineering.
• Designing for everyone: 'For some users we'd do A; for others B; for others C' without committing. Reads as decision avoidance.
• Reciting facts: 'CAP theorem says C, A, P; consistent hashing uses a ring; Raft has a leader' without applying any of it to the prompt. Reads as flashcard prep.
• Defending the first choice forever: when the interviewer challenges, the candidate doubles down. Senior signal is updating the design based on feedback.
• Drawing without speaking: silent pen + occasional glance up. Interviewers grade the conversation, not the diagram.
• Running out of time: 35 minutes deep in one component, 10 minutes left, 60% of the design unaddressed.

Implementation

A 45-minute timeline cheat sheet

0:00  prompt arrives
0:00 - 0:05  Requirements (functional, non-functional, constraints)
              Write 5-7 bullets visible to the interviewer.
0:05 - 0:08  Estimation (DAU, QPS, storage, bandwidth)
              Round aggressively; show the math.
0:08 - 0:13  Schema / API (3 endpoints + 3 tables, choose storage category)
0:13 - 0:18  HLD (8-10 boxes, data path + control path)
0:18 - 0:38  Deep dive (2-4 components: alternatives, trade-offs, choice, edge cases)
              Adjust based on interviewer signals.
0:38 - 0:43  Edge cases + monitoring + ops
0:43 - 0:45  Wrap-up: summary tied to requirements; what you did not cover

This is approximate. Real interviews compress and expand depending on prompt complexity and interviewer engagement. The point is the order, not the exact minutes.

A scripted opener (first 90 seconds)

Memorize a generic opener so your first 90 seconds are smooth even when nervous:

'Great. Before I jump in, I want to make sure I understand the scope. I'll start by asking some requirements questions, then do a quick back-of-envelope estimation, sketch out the API and data model, draw a high-level design, and then dive deep on the parts that are most interesting. Sound good?'

This frames the interview, signals you have a structure, and gives you a moment to settle. Most interviewers nod; some adjust the order. Either way you have started cleanly.

Drawing tactics

• Use the whiteboard or shared doc effectively; do not crowd one corner.
• Label boxes with the component category, not the product. 'Cache (Redis)' is fine; 'redis-cluster-1' is too much.
• Use consistent arrow direction: data flow direction, not control flow direction.
• Erase / strike through when you change your mind. The interviewer wants to see your thinking, including revisions.

Adjusting for time pressure

If you are running long:

• Skip stages but announce it: 'I'm going to skip detailed schema and just sketch the major entities; happy to come back if useful'.
• Pick fewer components for deep dive. One done well beats three done shallow.
• Always wrap up. A messy partial design without a wrap-up is worse than a clean limited design with one.

If you are running short:

• Add depth, not breadth. Go deeper on the chosen components.
• Add edge cases proactively. 'Let me mention a few failure modes I haven't addressed yet.'
• Sketch the next layer of design (ML ranking, analytics pipeline, multi-region).

When to Use

Use the RESHADED framework when

• Any open-ended system design prompt (the standard FAANG-style interview).
• 45-60 minute interviews with one main prompt.
• Senior+ interviews where the depth signal is what is being graded.

Adapt the framework when

• The prompt is very narrow ('design the ID generator for Twitter'): skip Estimation and HLD; spend the time on alternatives and trade-offs.
• The prompt is very broad ('design Uber'): spend more time in Requirements to scope ('let's focus on the rider-driver matching, not the maps or pricing').
• The interviewer has a specific direction ('how would you scale this read path?'): use the framework loosely; follow their lead.

Skip the framework when

• The interviewer asks pure conceptual questions ('explain CAP theorem'). That is a knowledge probe, not a design prompt.
• The interview is 20-30 minutes (often a screening). Compress everything; cover Requirements, HLD, one deep dive, wrap-up.

Other framework names

Different guides use different acronyms; the steps are largely the same:

• 4S (Scenarios, Service, Storage, Scale)
• RADIO (Requirements, Architecture, Data, Interfaces, Optimizations)
• RESHADED (the one used here)
• STAR-for-design (Situation, Task, Architecture, Result; less common)

Pick one and use it consistently. Switching frameworks mid-prep is a common source of confusion.

Case Studies

A clean RESHADED run on 'design Twitter'

Minute 0-5: ask scope. Confirm tweets, follows, timelines are in; DMs, ads, search out. Read-heavy (100:1). Eventual consistency on timeline. Three nines. Global eventually, single region for v1.

Minute 5-8: 200M DAU, 14k peak write QPS, 700k peak read QPS, 1 PB storage over 5 years, ~80 TB/day media.

Minute 8-13: API for create-tweet, get-timeline, follow. Tables for tweets, followers, users. Tweets in wide-column store (Cassandra-like); followers in graph or wide-column with user_id sharding; users in SQL.

Minute 13-18: HLD with CDN, API GW, tweet service, timeline service, fan-out service, tweet DB, timeline cache, media blob store.

Minute 18-38: deep dive on news-feed fan-out. Push vs pull vs hybrid. Pick hybrid with celebrity threshold. Walk through write path: tweet write -> queue -> fan-out service -> per-follower timeline cache. Walk through read path: timeline cache hit serves immediately; on miss, materialize from tweet DB. Discuss celebrity bypass. Discuss cache eviction policy. Discuss back-pressure.

Minute 38-43: edge cases. Hot key on a viral tweet -> shard cache by tweet_id; warm replicas. Fan-out lag during traffic spike -> SLO + back-pressure. New user with no follows -> cold start with default suggestions.

Minute 43-45: wrap up. Summarize trade-offs. Mention what was not covered (search, ranking, analytics, multi-region).

Result: clean conversation, every stage hit, deep on the right component, scope-aware wrap.

Anti-pattern: the no-requirements run

Minute 0: 'For Twitter I would use a Cassandra cluster, Redis cache, Kafka for events, and a CDN for media.'

Minute 5-30: drawing components, adding details, no scale numbers, no API.

Minute 30-40: interviewer asks 'how does timeline work?'. Candidate spends 10 minutes on news feed without ever discussing the celebrity problem.

Minute 40-45: interviewer prompts 'what about consistency?'. Candidate fumbles.

Result: technically not wrong, but no signal of scope reasoning, no trade-off conversation, looks like memorized recipe. Fails or grades low even when the components mentioned are correct.

A 'happy interviewer' adjustment

Minute 0-15: standard opener through HLD.

Minute 15: interviewer says 'this is great, let's spend the rest of our time on how you'd handle a sudden 10x traffic spike during a viral event'.

Candidate drops the planned deep dive, follows the lead. Spends 25 minutes on auto-scaling, queue back-pressure, cache warming, degradation modes, post-event analysis. Reads the room.

Result: strong signal even though the framework was abandoned mid-stream. The framework is a default, not a requirement.

Quick Review

• RESHADED: Requirements, Estimation, Schema / API, HLD, Architecture deep dive, Edge cases, Done.
• Spend ~5 minutes on Requirements to align scope; do not skip this stage.
• Estimation is back-of-envelope: DAU, QPS, storage, bandwidth. Round aggressively.
• Schema and API before HLD; the contract drives the components.
• HLD is one diagram with 5-10 boxes. Data path first, then control path.
• Architecture deep dive is 80% of the senior signal. Pick 2-4 components; alternatives -> trade-offs -> choice -> edge cases.
• Surface edge cases proactively. Hot keys, celebrity problem, partial failure, consistency, abuse.
• Wrap up tying back to requirements; mention what you did not cover.
• Read the interviewer constantly. The framework is the default; their signals override it.