The RESHADED Framework

Why You Need a Framework

System design interviews are deliberately open-ended. The interviewer gives you a vague prompt — "Design Twitter" or "Build a notification service" — and then watches how you decompose ambiguity into structure. Without a repeatable framework, most candidates either ramble without direction or dive straight into implementation details before agreeing on the problem. Both patterns signal poor engineering judgment.

The RESHADED framework gives you a consistent mental checklist that ensures you cover every dimension an interviewer cares about, in the right order. It stands for: Requirements, Estimation, Storage schema, High-level design, API design, Detailed design, Evaluation, Distinctive component.

The Eight Steps of RESHADED

R — Requirements

Start by separating functional requirements (what the system must do) from non-functional requirements (how well it must do it). Ask clarifying questions to pin down scope. Never assume — interviewers reward candidates who ask smart questions because it mirrors real engineering work.

E — Estimation

Back-of-the-envelope math grounds your design in reality. Estimate QPS (queries per second), storage requirements, and bandwidth needs. These numbers drive every subsequent decision — whether you need sharding, caching, CDNs, and how many servers to provision.

S — Storage Schema

Choose your database type (SQL vs NoSQL, relational vs document vs column-store vs graph) and define your primary data models. Explain the access patterns driving your choice. Identify your primary keys and how you will handle sharding keys to avoid hot spots.

H — High-Level Design

Draw the system's major components on a whiteboard: clients, load balancers, application servers, databases, caches, CDNs, and message queues. At this stage, stay at the service boundary level — do not detail internal algorithms yet. Get alignment from the interviewer before going deeper.

A — API Design

Define the public API contracts for your core operations. Specify endpoints, HTTP methods, request parameters, and response shapes. Good API design demonstrates that you think about the client experience and not just the server internals.

# Post a tweet
POST /v1/tweets
Authorization: Bearer {token}
Content-Type: application/json

{
  "text": "Hello, world!",
  "media_ids": ["m_123", "m_456"]
}

# Response
HTTP 201 Created
{
  "tweet_id": "t_789",
  "created_at": "2024-01-15T10:30:00Z",
  "author_id": "u_456"
}

# Get home timeline
GET /v1/timeline?cursor={cursor}&limit=20
Authorization: Bearer {token}

# Response
HTTP 200 OK
{
  "tweets": [...],
  "next_cursor": "eyJ0aW1lc3RhbXAiOiAxNzA1MzE0MjAwfQ=="
}

D — Detailed Design

Zoom in on the two or three most technically interesting components. The interviewer will often guide you here — follow their lead. This is where you discuss fan-out strategies, sharding schemes, consensus algorithms, or custom data structures. Demonstrate depth without losing the big picture.

E — Evaluation

Critically evaluate your own design. Identify failure modes (what happens when the database goes down?), bottlenecks (which component hits capacity first?), and trade-offs (what did you sacrifice for performance?). This self-evaluation shows engineering maturity — great engineers know the limits of their own designs.

D — Distinctive Component

Every great system design answer has a "wow moment" — one area where you go noticeably deeper or propose something non-obvious. This could be a clever sharding scheme, a specific algorithm for ranking, an unusual caching strategy, or a reliability pattern from a real-world system you've studied. The distinctive component is what interviewers remember after the interview.

RESHADED at a Glance