All chapters

Chapter 68

System Design in 45 Minutes (The RESHADED Framework)

System Design in 45 Minutes: The RESHADED Framework

System design interviews are the most open-ended, high-signal rounds in technical hiring. They test your ability to think at scale, make tradeoffs, and communicate complex ideas clearly. For international candidates, this round is a major differentiator because it rewards structured thinking over cultural fluency.

The RESHADED framework gives you a repeatable, time-boxed structure that covers every dimension interviewers care about. Here is exactly how to use it.

The RESHADED Framework: 8 Steps in 45 Minutes

Each letter in RESHADED maps to a phase of your system design answer. Here is the recommended time allocation:

  1. R — Requirements (3-4 minutes)
  2. E — Estimation (3-4 minutes)
  3. S — Storage (4-5 minutes)
  4. H — High-Level Design (5-6 minutes)
  5. A — API Design (4-5 minutes)
  6. D — Detailed Design (8-10 minutes)
  7. E — Evaluation (5-6 minutes)
  8. D — Deployment (3-4 minutes)

Step 1: Requirements (3-4 Minutes)

Never start designing before you know what you are building. Split requirements into two categories:

Functional Requirements: What does the system do? Ask clarifying questions to narrow the scope. For example, if the prompt is "Design Twitter," ask: Are we building the feed, posting, search, or all three? Do we need direct messaging? What about notifications?

Non-Functional Requirements: What qualities must the system have? Think about:

  • Scale — How many users? How many requests per second?
  • Availability — Can we tolerate downtime? (99.9% vs 99.99%)
  • Latency — What is the acceptable response time?
  • Consistency — Do we need strong consistency or is eventual consistency acceptable?
  • Durability — Can we lose data?

Pro tip: Write your requirements on the whiteboard. This shows the interviewer you are methodical, and it gives you a checklist to refer back to during the evaluation phase.

Step 2: Estimation (3-4 Minutes)

Back-of-the-envelope math proves you can think at scale. Estimate these numbers:

  • Daily active users (DAU): Start with a reasonable assumption (e.g., 100M DAU for a large social platform).
  • Queries per second (QPS): DAU multiplied by average actions per user, divided by 86,400 seconds. Then multiply by 2-3x for peak traffic.
  • Storage: Average object size multiplied by the number of objects per day, multiplied by retention period.
  • Bandwidth: QPS multiplied by average response size.

You do not need exact numbers. The interviewer wants to see that you can reason about scale and that your design choices match the scale you estimated.

Step 3: Storage (4-5 Minutes)

Define your data model and choose the right storage technologies:

  • Relational (PostgreSQL, MySQL): When you need ACID transactions, complex joins, or structured data with clear relationships.
  • NoSQL (DynamoDB, Cassandra): When you need horizontal scalability, flexible schemas, or write-heavy workloads.
  • Cache (Redis, Memcached): For frequently accessed data that can tolerate staleness.
  • Blob storage (S3): For images, videos, and large files.
  • Search index (Elasticsearch): For full-text search requirements.

Sketch out your key tables or collections, including the primary fields and relationships. Do not over-detail here — just enough to show you have thought about how data flows through the system.

Step 4: High-Level Design (5-6 Minutes)

Draw the big boxes and arrows. This is the architecture overview that connects clients to services to storage. Include:

  • Client (web, mobile)
  • Load balancer
  • API gateway
  • Core services (identify 2-4 main services)
  • Databases and caches
  • Message queues (if async processing is needed)
  • CDN (if serving static content)

Keep it simple. The interviewer wants to see that you can decompose a complex system into manageable components. You will add detail in the next steps.

Step 5: API Design (4-5 Minutes)

Define the key API endpoints for your core functionality. For each endpoint, specify:

  • HTTP method and path
  • Request parameters
  • Response format
  • Authentication requirements

For example, for a URL shortener: POST /api/v1/urls with a body containing the long_url and optional custom_alias, returning the short_url and expiration time.

This step demonstrates that you think about the system from the user perspective, not just the backend.

Step 6: Detailed Design (8-10 Minutes)

This is where you spend the most time and where you differentiate yourself. Pick the 2-3 most interesting or challenging components and dive deep. Common deep-dive topics:

  • Database sharding strategy: How do you partition data? By user ID, by geography, by time?
  • Caching strategy: Cache-aside, write-through, or write-behind? Cache invalidation approach?
  • Message queue processing: How do you handle failures? Retries? Dead letter queues?
  • Consistency mechanisms: How do you handle concurrent writes? Optimistic locking? CRDTs?
  • Rate limiting: Token bucket vs sliding window? Per-user vs global?

The interviewer may guide you toward specific areas they care about. Follow their lead — it shows you can collaborate and prioritize.

Step 7: Evaluation (5-6 Minutes)

Go back to your requirements and evaluate your design against each one:

  • Scalability: Can this handle 10x growth? Where are the bottlenecks?
  • Availability: What happens if a service goes down? Do you have redundancy?
  • Latency: Where are the slow paths? Can caching help?
  • Consistency: Are there edge cases where users see stale data?

Proactively identifying weaknesses shows maturity. Every system has tradeoffs — the interviewer wants to see that you understand yours.

Step 8: Deployment (3-4 Minutes)

If time allows, discuss how you would deploy and operate this system:

  • Monitoring: Key metrics to track (latency percentiles, error rates, queue depth).
  • Alerting: What triggers a page? What is informational?
  • Rollout strategy: Canary deployments, blue-green, feature flags.
  • Disaster recovery: Multi-region replication, backup strategy, failover.

Common Mistakes to Avoid

  • Jumping into detailed design too early. If you skip requirements and estimation, your design may solve the wrong problem at the wrong scale.
  • Over-engineering. Do not add microservices, Kafka, and Kubernetes to a system that serves 1,000 users. Match complexity to scale.
  • Monologuing. System design is a conversation. Pause frequently, ask if the interviewer wants you to go deeper on a topic, and invite their input.
  • Ignoring tradeoffs. Never say "we should use X" without explaining why and what you are giving up.
  • Not practicing with a timer. 45 minutes goes fast. Practice the full RESHADED flow end-to-end until the pacing feels natural.

Preparation Strategy for International Candidates

System design interviews level the playing field for international candidates because they reward deep technical knowledge over cultural fluency. To prepare effectively:

  • Practice 2-3 full system design problems per week using RESHADED timing.
  • Study real architectures from engineering blogs (Uber, Netflix, Instagram, Twitter).
  • Build vocabulary for explaining tradeoffs clearly in English — practice saying "the tradeoff here is..." and "I chose X over Y because..."
  • Record yourself and review for clarity, pacing, and technical accuracy.
  • Use the framework as a safety net — even when nervous, RESHADED gives you the next step.

The RESHADED framework is not just a memorization tool. It is a mental model for how experienced engineers actually think about systems. Master it, and you will not only pass system design interviews — you will demonstrate the kind of structured thinking that makes companies want to sponsor your visa.