The 14-Day System Design Interview Plan That Actually Works

What This Blog Covers

• A day-by-day 14-day plan that builds system design interview confidence from scratch
• Why 14 days of focused practice produces better results than 60 days of unfocused study
• The specific activities for each day, including time estimates and expected outputs
• How to track progress so you know you are improving, not just studying
• The three skills that matter most in 14 days (and everything else you should ignore)

Fourteen days is not a lot of time. But it is enough time to go from "I have no idea how to approach system design" to "I can hold my own in an interview."

Not because 14 days is magic.

Because 14 days of focused, daily practice, with the right activities in the right order, builds the three core skills that interviewers actually evaluate.

Most candidates prepare for system design by reading. They read about databases, caching, load balancers, message queues, and microservices. They read for weeks. They feel knowledgeable. Then they sit in an interview and cannot produce a coherent design under time pressure because reading is not the same as doing.

This plan is different. It is structured around doing, not reading.

Every day has a specific output: a written design, a practiced answer, a recorded mock, or a timed exercise. By day 14, you have produced 14 outputs. Those outputs are the evidence of your preparation, and the process of creating them is what builds the skills.

The three skills this plan focuses on, in order of importance: making decisions with trade-off reasoning (why this, not that), quantifying your claims (specific numbers that justify scaling decisions), and communicating a design clearly under time pressure (structured, signal-dense delivery).

Everything else is secondary for a 14-day timeline.

Phase 1: Foundations (Days 1-4)

The goal of phase 1 is to build the minimum knowledge base needed to make decisions. Not encyclopedic knowledge. Just enough to justify choices.

Day 1: The Six Core Databases

Study six databases in one day. Not deeply. Just enough to answer three questions for each: when to use it, when not to use it, and what the trade-off is.

PostgreSQL: Use for relational data with joins and transactions. Not for write-heavy workloads exceeding 30,000 writes per second. Trade-off: single-leader write scaling.

Redis: Use for caching, sessions, and leaderboards. Not for data exceeding RAM. Trade-off: data loss if persistence fails, $6/GB/month of RAM.

DynamoDB: Use for simple key-value lookups at any scale. Not for ad-hoc queries or joins. Trade-off: expensive at extreme scale, no query flexibility.

Cassandra: Use for write-heavy time-series data. Not for ad-hoc queries or when the access pattern is unknown. Trade-off: must design data model around query patterns.

Elasticsearch: Use for full-text search with relevance ranking. Not as the primary data store. Trade-off: not a source of truth, 1-second refresh delay.

MongoDB: Use for flexible document schemas with varying attributes. Not for heavy relational queries. Trade-off: application-level joins for cross-collection queries.

Day 1 output: A one-page cheat sheet with three sentences per database (18 sentences total). For a faster overview of foundational concepts, System Design Concepts You Can Learn in 60 Mins covers the essentials concisely.

Day 2: Eight Core Concepts

Study eight concepts at a practical level. For each, understand what it does and when to use it.

Load balancing: L4 (transport layer, fast, no content awareness) vs L7 (application layer, path-based routing, SSL termination). Use L7 when you need routing by URL path or header.

Caching: Cache-aside pattern (application checks cache, falls back to database). TTL for expiration. Event-driven invalidation for consistency-critical data.

Replication: Leader-follower for read scaling. Quorum (W + R > N) for strong consistency. Eventual consistency when staleness is acceptable.

Sharding: Consistent hashing for even distribution. Shard key selection determines query efficiency. Hot keys require special handling.

Message queues: Kafka for ordered, replayable event streams. SQS for simple task queues. At-least-once delivery with idempotent consumers.

API design: REST for CRUD operations. gRPC for internal service-to-service calls with high throughput and schema enforcement.

Consistency models: Strong consistency (every read returns the most recent write). Eventual consistency (reads may return stale data, but converge over time).

Rate limiting: Token bucket for smooth rate enforcement. Sliding window for accurate per-user limiting. Redis for distributed counters.

Day 2 output: A one-page cheat sheet with two sentences per concept (16 sentences total).

Day 3: The Three-Layer Answer Structure

Today is entirely about practicing one skill: producing decision-reasoning-trade-off answers for any component.

Pick 10 components (database, cache, load balancer, message queue, API gateway, CDN, search engine, notification service, rate limiter, file storage). For each, write a three-layer answer in the context of a social media platform.

Example for database: "I chose PostgreSQL for the user profile service because profiles require joins (user linked to followers linked to settings) and transactional updates. The trade-off is single-leader write scaling, but profile writes are infrequent (once per signup plus occasional updates), so write throughput is not a concern."

Practice saying each answer out loud. Time yourself. Target: 15 seconds per answer.

Day 3 output: 10 written three-layer answers, each practiced aloud. For understanding the complete decision framework, How to Think About System Design: Layers, Components, and the Decisions Between Them covers the mental model behind this structure.

Day 4: Back-of-the-Envelope Math

Today is entirely about practicing one skill: estimating RPS, storage, and bandwidth for any system.

The three formulas:

Requests per second: DAU multiplied by actions per user per day divided by 86,400. Peak: average multiplied by 3 to 5.

Storage per year: records per day multiplied by average record size multiplied by 365.

Bandwidth: RPS multiplied by average response size.

Practice these calculations for five systems: Twitter (500M DAU, 10 reads per day), Instagram (500M DAU, 30 views per day), Uber (20M rides per day), WhatsApp (2B users, 50 messages per day), and YouTube (2B DAU, 5 video views per day).

Day 4 output: Calculation sheets for all five systems. Each calculation should take under 60 seconds.

Phase 2: Design Practice (Days 5-9)

The goal of phase 2 is to practice designing complete systems under time pressure. One system per day.

Day 5: Design a URL Shortener

This is the simplest system design problem. Use it to practice the full interview structure.

Minutes 1-3: Requirements. How many URLs shortened per day (100 million)? Read-to-write ratio (100:1)? Custom aliases? Expiration? Analytics?

Minutes 4-10: High-level design. Write path: client submits URL, service generates short code (base62 encoding of auto-incrementing ID or random 7-character string), stores mapping in database, returns short URL. Read path: client requests short URL, service looks up mapping, returns 301 redirect.

Minutes 11-25: Deep dive. Short code generation (collision handling with random vs sequential). Database choice (DynamoDB for simple key-value lookup by short code). Caching (Redis for hot URLs, 80% of traffic hits 20% of URLs). Read path latency target: under 10ms (cache hit) or under 50ms (database lookup).

Minutes 26-35: Failure modes and scale. What if DynamoDB is down (serve from cache for reads, queue writes in Kafka). Scale evolution (at 10 billion URLs, partition the database by short code prefix).

Day 5 output: A written design covering all four phases. Record yourself presenting it in 35 minutes.

Day 6: Design a Chat/Messaging System

Different patterns: real-time delivery, connection management, message ordering.

Focus areas: WebSocket connection management (connection server fleet with Redis-based connection registry), message ordering (partition by conversation_id in Kafka), offline delivery (store messages in database, push notification when recipient reconnects), and group messaging (fan-out to all group member connections).

Day 6 output: Written design with focus on real-time patterns. Record yourself.

Day 7: Design a News Feed

Different patterns: fan-out strategies, pre-computation, ranking.

Focus areas: Push vs pull fan-out (push for users with fewer than 10,000 followers, pull for celebrities). Pre-computed feed stored in Redis (list of post IDs per user). Ranking pipeline (chronological base with engagement-based re-ranking). Cache invalidation (new posts trigger feed update for followers). For understanding the trade-offs between read-heavy and write-heavy access patterns, Read-Heavy vs Write-Heavy Systems: The Framework FAANG Interviewers Use covers the decision framework.

Day 7 output: Written design with focus on fan-out trade-offs. Record yourself.

Day 8: First Mock Interview

Do a 45-minute mock interview with a friend, study partner, or online platform. Do not choose the problem in advance. Let the interviewer pick.

After the mock, write down: what went well (specific moments), what went poorly (specific moments), and three actions to improve.

Day 8 output: Mock recording plus written self-assessment with three improvement actions.

Day 9: Review and Gap Analysis

Review all three designs (days 5, 6, 7) and the mock (day 8). For each design, check:

Did I start with requirements? (If not, practice the opening.) Did I quantify? (If not, add numbers to each design.) Did I mention failure modes? (If not, add failure analysis.) Did I name alternatives? (If not, add rejected alternatives to each decision.)

Rewrite the weakest design incorporating all the gaps.

Day 9 output: Gap analysis document plus one rewritten design.

Phase 3: Advanced Skills (Days 10-12)

The goal of phase 3 is to add the signals that separate good answers from great answers.

Day 10: Failure Mode Deep Dive

For all three systems (URL shortener, chat, news feed), write a failure analysis for the three most critical components. For each: what fails, what the user sees, how long until recovery, what prevents data loss.

Practice presenting each failure analysis in 30 seconds. Total: nine failure analyses, each 30 seconds = 4.5 minutes of practiced failure content.

Day 10 output: Nine written failure analyses, each practiced aloud.

Day 11: Scale Evolution Practice

For all three systems, present the design at three checkpoints: 10,000 users, 1 million users, and 100 million users. For each checkpoint, name what changes from the previous one and why.

Practice presenting each scale evolution in 90 seconds. Total: three scale evolutions, each 90 seconds = 4.5 minutes of practiced scaling content.

Day 11 output: Three written scale evolutions, each practiced aloud.

Day 12: Second Mock Interview

Another 45-minute mock. Compare with the first mock from day 8. Specifically check: am I starting with requirements? Am I quantifying? Am I mentioning failure modes without being asked? Am I naming alternatives?

Day 12 output: Mock recording plus comparison with day 8 mock.

Phase 4: Polish (Days 13-14)

Day 13: Rapid-Fire Component Drill and Company-Specific Preparation

Morning: practice the three-layer answer for 15 components in rapid succession. Target: 15 seconds each, 4 minutes total.

Afternoon: if interviewing at a specific company, design one system that matches their domain. Amazon: e-commerce checkout flow. Meta: social graph and friend suggestions. Google: search ranking pipeline. Netflix: video streaming with adaptive bitrate.

Day 13 output: 15 rapid-fire three-layer answers plus one company-specific design.

Day 14: Final Mock and Light Review

Morning: third and final mock interview. This should feel comfortable. You are not learning. You are rehearsing.

Afternoon: review your three one-page design summaries (URL shortener, chat, news feed). Read through your cheat sheets (databases, concepts). Do not study new material. Trust the 13 days of preparation.

Evening: rest. Get sleep. The preparation is done.

Day 14 output: Final mock recording. Confidence.

For structured practice with additional system design problems beyond this plan, the Grokking the System Design Interview course covers 25+ design problems with trade-off analysis and scaling discussions that extend the foundation built in these 14 days.

The Daily 15-Minute Baseline

In addition to each day's main activity, do this 15-minute routine every single day:

5 minutes: Back-of-the-envelope math for a random system. Calculate RPS, storage, and bandwidth.

5 minutes: Three-layer drill for three random components. Decision, reasoning, trade-off. 15 seconds each.

5 minutes: Failure mode for one component from yesterday. What fails, user impact, recovery time.

This baseline is the compounding mechanism. By day 14, you have done 14 math exercises, 42 three-layer drills, and 14 failure analyses. These micro-practices become automatic habits.

How to Know You Are Ready

By day 14, you should be able to:

Start any design with 3 to 5 constraint-finding questions without hesitation.

Calculate RPS, storage, and bandwidth in under 60 seconds for any system.

Produce a three-layer answer (decision, reasoning, trade-off) for any component in under 15 seconds.

Present failure modes for any critical component without being asked.

Walk through three scale checkpoints (10K, 1M, 100M users) in under 90 seconds.

Hold a 45-minute system design conversation that feels collaborative, not interrogative.

If you can do all six, you are ready.

If you cannot do one or two, spend the remaining time on those specific gaps. Do not study new material. Practice the weak skill.