System Design Interview Prep: The Definitive Guide to Landing L5+ Roles

The Complete Interview Framework (Your Default Flow)

The difference between candidates who pass and those who fail isn’t knowledge—it’s structure. Strong candidates follow a repeatable framework that works across any system design problem, from URL shorteners to video streaming platforms.

This framework is your default flow. Memorize it. Practice it until it becomes automatic. When you walk into an interview and your mind goes blank, this structure will carry you through.

The Eight-Phase Framework

Phase 1: Clarify the Problem (5 minutes). Don’t start designing yet. Your first job is understanding what you’re actually building. Ask about functional requirements—what features must the system support? Ask about scale—how many users, requests per second, data volume? Ask about constraints—latency requirements, consistency needs, budget limitations?

The magic question that separates senior candidates: “What are we optimizing for?” Is this system read-heavy or write-heavy? Do we prioritize availability over consistency? Is cost a primary concern? This single question demonstrates you think in tradeoffs.

Phase 2: Establish Requirements & Constraints (5 minutes). State your assumptions explicitly. “I’m assuming 100 million daily active users with peak traffic at 10x average. I’m assuming we need 99.9% availability. I’m assuming reads vastly outnumber writes.” Write these down where the interviewer can see them. This prevents misunderstandings and shows systematic thinking.

Define success metrics. For a social feed: “Success means sub-200ms feed load times with personalized content for each user.” For a payment system: “Success means zero data loss and strong consistency for transactions.” Metrics anchor your design decisions.

Phase 3: Capacity Estimation (3-5 minutes). Do back-of-the-envelope math. How much storage do you need? What’s your expected throughput? How many servers will this require? These numbers don’t need to be perfect—they need to be reasonable and demonstrate you can think quantitatively.

Example: “With 100M daily users averaging 50 feed loads per day, that’s 5B requests daily or roughly 60K requests per second at peak. If each request is 500KB, we’re moving 30TB of data daily for feeds alone.” This level of estimation is impressive, not required—but it separates senior candidates.

Share this framework

Phase 4: API Design (5 minutes). Define your key APIs before diving into architecture. What are the core operations? For Instagram: uploadPhoto(), getFeed(), likePhoto(), followUser(). For each API, specify inputs, outputs, and error cases.

This forces you to think about the client-server contract before implementation details. It also gives the interviewer confidence you understand interface design—a critical senior skill.

Phase 5: Data Model (5 minutes). What does your data look like? What database tables or document schemas do you need? What are the relationships? What are your access patterns?

Strong candidates connect data model to access patterns: “Users will query by user_id for profile data, and by following_list for feed generation. This suggests we need indexes on both fields. The feed generation query is complex, so we might denormalize and precompute feeds.”

Phase 6: High-Level Architecture (15-20 minutes). Now you can draw boxes and arrows. Start simple—clients, API servers, databases, caches. Explain the data flow for your core use cases. Then add complexity based on requirements: load balancers for scale, CDN for static content, message queues for async processing.

Name each component and justify it. “I’m adding Redis here because 80% of profile requests are for the same 1,000 power users. Caching reduces database load and cuts latency from 100ms to 5ms.”

Phase 7: Deep Dives (15-20 minutes). The interviewer will steer you toward 2-3 interesting components. This is where you demonstrate depth. If they ask about the feed generation algorithm, walk through ranking signals, caching strategies, and performance optimizations. If they ask about data consistency, discuss transaction boundaries, eventual consistency models, and conflict resolution.

Don’t try to deep dive on everything—you don’t have time. Follow the interviewer’s lead. They’re looking for depth in your areas of strength.

Phase 8: Identify Bottlenecks & Discuss Tradeoffs (5-10 minutes). Step back and critique your own design. Where will this break under load? The database write path? The feed generation computation? The network bandwidth for video uploads? For each bottleneck, propose solutions and discuss tradeoffs.

“The main bottleneck is the database write path when users upload photos. We could shard by user_id to distribute load, but that complicates follower queries. Alternatively, we could use a write-ahead log and batch writes, which increases latency slightly but handles burst traffic better.”

Framework In Action: URL Shortener Walkthrough

Let’s apply this framework to a classic problem: designing a URL shortener like bit.ly.

Clarify: “Are we supporting custom short URLs or auto-generated only? Do we need analytics on click counts? What’s the expected scale—millions of URLs or billions?”

Requirements: “Assuming 100M new URLs per month, 10B clicks per month, we need high availability for redirects but can tolerate brief inconsistency for new URLs. We’re optimizing for read performance.”

Capacity: “100M URLs monthly = 40 new URLs per second average, 400 at peak. 10B clicks = 4,000 redirects per second average. For storage: 100M URLs × 500 bytes average = 50GB monthly, 600GB yearly. Easily fits in memory for hot URLs.”

API: createShortURL(originalURL) → shortCode. redirect(shortCode) → originalURL. getAnalytics(shortCode) → clickCount, lastClicked.

Data Model: Table: url_mappings (short_code, original_url, created_at, clicks). Index on short_code for fast lookups. Clicks updated async to avoid write bottlenecks.

Architecture: Clients → Load Balancer → App Servers → Redis Cache (for hot URLs) → Database (PostgreSQL). Separate write path through message queue for analytics updates.

Deep Dive (short code generation): “We need unique 7-character codes using [A-Za-z0-9], giving us 62^7 = 3.5 trillion possible codes. We could use a counter and base62 encode it, but that’s predictable. Better: generate random codes and check for collisions. With 100M URLs, collision probability is negligible. If we detect a collision, retry with a new random code.”

Bottlenecks: “Main bottleneck is database reads for redirect lookups. Solution: aggressive caching in Redis with LRU eviction. 80/20 rule means 20% of URLs get 80% of traffic, so a 10GB cache covers most requests. Write bottleneck for analytics: use async queue and batch updates every 60 seconds.”

Notice how the framework structures the conversation. You’re not jumping around—you’re methodically building up the design while demonstrating senior-level thinking at each phase.

Adapting the Framework

Not every interview follows this exact sequence. Sometimes the interviewer jumps straight to “how would you scale this?” Sometimes they want to deep dive on one specific component. The framework is your default, not a rigid script.

When the interviewer redirects you, follow their lead. “You mentioned scalability—let me focus on that. The current bottleneck would be…” This shows you’re collaborative and can adapt.

If you’re running short on time, explicitly state what you’re skipping: “In the interest of time, I’ll assume we’re using industry-standard OAuth for authentication and focus on the core data pipeline.” This demonstrates time management and prioritization—both senior skills.

The framework becomes internalized through practice. After 20-30 mock interviews using this structure, you’ll do it automatically. That’s when you can focus on the interesting technical discussions instead of worrying about what to say next.

Core Building Blocks You Must Master

System design interviews test whether you know when to use specific technologies and patterns. You don’t need to memorize every database or framework—you need to understand the fundamental building blocks and their tradeoffs.

This chapter covers the components that appear in nearly every system design interview. Master these, and you can design 90% of systems.

Caching: The Universal Performance Multiplier

When to use caching. Any time you have expensive computations or frequently accessed data. Caching works best when you have a small set of hot data accessed repeatedly. The 80/20 rule applies: 20% of your data gets 80% of requests.

Cache placement strategies. Client-side caches (browser caching for static assets). Server-side caches (Redis, Memcached between app and database). CDN caches (geographically distributed for static content). Each layer serves a different purpose and has different invalidation challenges.

Eviction policies. LRU (Least Recently Used) evicts the oldest accessed item—simple and effective for most use cases. LFU (Least Frequently Used) evicts items accessed least often—better for stable access patterns. FIFO (First In First Out) is simpler but less effective. TTL (Time To Live) sets expiration times—critical for data that changes.

Cache invalidation—the hard problem. Write-through caches update both cache and database synchronously—consistent but slower. Write-behind caches update cache first, database async—faster but risks data loss. Cache-aside (lazy loading) only caches on cache misses—simpler to implement but first request is slow.

Common pitfalls. Over-caching can lead to serving stale data. Under-caching wastes the performance benefit. Cache stampede happens when many requests hit an expired cache key simultaneously and all try to regenerate it. Solution: lock the key during regeneration or use probabilistic early expiration.

Load Balancing: Distributing Traffic

Load balancer types. Layer 4 (transport layer) balancers make decisions based on IP and port—fast but limited visibility. Layer 7 (application layer) balancers can route based on HTTP headers, cookies, URL paths—more flexible but higher overhead.

Distribution algorithms. Round-robin sends requests to servers in rotation—simple and fair. Least connections routes to the server with fewest active connections—better for long-lived connections. Weighted round-robin assigns different weights to servers based on capacity. Consistent hashing minimizes redistribution when servers are added or removed.

Health checks. Active health checks periodically ping servers to verify they’re healthy. Passive health checks monitor actual traffic and mark servers unhealthy after multiple failures. Combine both for robust failure detection.

When to avoid load balancers. Small systems where a single server suffices. Systems where sticky sessions (session affinity) would defeat the purpose of load balancing. Edge cases where the load balancer becomes the bottleneck—though this is rare with modern load balancers.

Message Queues & Stream Processing

When queues solve problems. Decoupling producers from consumers—they can operate at different speeds. Handling traffic spikes—the queue buffers requests during bursts. Enabling async processing—critical for operations that don’t need immediate responses. Guaranteeing message delivery—queues persist messages until consumed.

Queue vs. stream. Queues (RabbitMQ, SQS) deliver each message to one consumer—good for task distribution. Streams (Kafka, Kinesis) deliver messages to multiple consumers—good for event logs and analytics. Streams maintain message order and allow replay; queues typically don’t.

Delivery guarantees. At-most-once: messages might be lost, never duplicated—fastest but risky. At-least-once: messages guaranteed delivered but might duplicate—most common in practice. Exactly-once: messages delivered once and only once—hardest to implement, requires deduplication or idempotent operations.

Common patterns. Fan-out: one message produces multiple tasks. Fan-in: multiple messages combine into one result. Dead letter queues: failed messages go to a separate queue for analysis. Priority queues: high-priority messages process first.

Share this decision tree

Database Selection: SQL vs NoSQL

When to use SQL (relational databases). You need ACID transactions—financial systems, inventory management, anything where consistency is critical. You have complex queries with joins across multiple tables. Your data has clear relationships and a stable schema. Examples: PostgreSQL, MySQL.

When to use NoSQL. You need horizontal scalability beyond what SQL can easily provide. Your data is unstructured or semi-structured. You can tolerate eventual consistency. You have simple access patterns that don’t require complex joins. Types: Document stores (MongoDB), key-value stores (DynamoDB, Redis), column-family stores (Cassandra), graph databases (Neo4j).

The false dichotomy. Many systems use both. SQL for transactional data, NoSQL for high-volume logging or analytics. SQL for user accounts, NoSQL for session state. The right answer is often “it depends on the access pattern.”

Indexes and query optimization. Indexes speed up reads but slow down writes—crucial tradeoff. B-tree indexes work for range queries. Hash indexes work for exact matches. Full-text indexes enable search. Covering indexes include all query fields, eliminating table lookups. Know when to index and when indexes hurt more than help.

Sharding & Partitioning: Scaling Data Storage

Why sharding matters. A single database server has limits—CPU, memory, disk I/O, network bandwidth. Vertical scaling (bigger servers) eventually hits physical and economic limits. Horizontal scaling (sharding) distributes data across multiple servers to exceed single-server limits.

Sharding strategies. Range-based sharding divides data by ranges (users A-M on server 1, N-Z on server 2)—simple but can create hot spots. Hash-based sharding uses a hash function to distribute data evenly—balanced but makes range queries harder. Geography-based sharding puts data close to users—great for latency but complicates global operations. Directory-based sharding maintains a lookup table—flexible but adds a lookup step.

Challenges with sharding. Cross-shard queries are expensive—design your shard key to minimize them. Rebalancing when adding shards requires data migration. Transactions across shards are complex—most systems avoid them. Hot shards (celebrity problem) can develop if data isn’t evenly distributed.

Consistent hashing. This technique minimizes data movement when servers are added or removed. Instead of rehashing all keys, only a fraction move. Critical for distributed caches and databases. Know the concept and when to mention it.

Replication & Consistency Models

Why replicate data. High availability—if one replica fails, others serve requests. Read scalability—distribute read traffic across replicas. Disaster recovery—replicas in different data centers survive regional failures. Lower latency—replicas geographically close to users reduce response times.

Replication strategies. Master-slave (primary-replica): writes go to master, reads from replicas—simple but writes don’t scale horizontally. Master-master (multi-master): writes go to any master—scales writes but requires conflict resolution. Quorum-based: writes/reads require majority agreement—balances consistency and availability.

CAP theorem in practice. You can’t have Consistency, Availability, and Partition-tolerance all at once. In practice, partitions happen, so you choose between consistency (CP systems like HBase) or availability (AP systems like Cassandra). Most systems choose availability and tune consistency levels.

Consistency models. Strong consistency: reads always reflect the latest write—easier to reason about but expensive. Eventual consistency: replicas converge over time—better performance but requires handling stale reads. Read-after-write consistency: users see their own writes immediately—common middle ground for user-facing features.

Rate Limiting & Backpressure

Why rate limiting matters. Prevents abuse—malicious users can’t overwhelm your system. Protects downstream services—ensures you don’t accidentally DDoS your own database. Enforces fair usage—prevents power users from monopolizing resources. Enables tiered pricing—different rate limits for different plan levels.

Rate limiting algorithms. Fixed window: allow N requests per minute—simple but can allow 2N requests across window boundaries. Sliding window: more accurate but requires more state. Token bucket: refill tokens at fixed rate, consume on request—smooth bursts. Leaky bucket: requests enter a queue, process at fixed rate—enforces strict rate.

Where to implement rate limiting. API gateway (centralized, consistent). Application servers (distributed, scales horizontally). Database layer (protects the most critical resource). Client-side (best user experience but not secure).

Backpressure strategies. When downstream services are overwhelmed, you need backpressure: reject requests early with 503 errors. Queue requests and process when capacity available. Degrade gracefully by returning cached or partial data. Shed load by dropping low-priority requests.

These building blocks combine to solve most system design problems. In interviews, you’ll rarely design something entirely novel—you’ll assemble these components in specific ways to meet requirements. Mastery means knowing not just what each does, but when to use it and what it costs.

Reliability & Production Thinking (What Most Candidates Miss)

This is where senior candidates distinguish themselves. Anyone can design a system that works when everything goes right. Senior engineers design systems that keep working when things go wrong—and in production, things always go wrong.

Interviewers probe reliability to see if you’ve operated real systems or just designed theoretical ones. They want to know: have you been paged at 3 AM to fix a production incident?

The SLO/SLI Mindset

Service Level Indicators (SLIs) are the metrics you measure: latency, error rate, throughput, availability. For a web application: 95th percentile latency under 200ms, error rate below 0.1%, availability 99.9%.

Service Level Objectives (SLOs) are the targets you commit to: “99.9% of requests will complete in under 200ms.” SLOs drive design decisions—if you need 99.99% availability, you need different architecture than 99% availability.

In interviews, mentioning SLOs shows production maturity. “Given our 99.9% availability requirement, we need redundancy at every layer. A single database server gives us at best 99% uptime, so we need replicas across availability zones.”

Error budgets are the flip side of SLOs. If you promise 99.9% availability, you have a 0.1% error budget—about 43 minutes of downtime per month. This budget informs risk decisions: do you deploy on Friday, or wait until Monday?

Designing for Failure

Everything fails eventually. Servers crash. Networks partition. Databases slow down. Downstream APIs return errors. Power outages happen. The question isn’t if components will fail, but how your system behaves when they do.

Single points of failure (SPOFs). Identify them systematically. If your load balancer fails, does the whole system go down? If your primary database fails, can you failover to a replica? If your authentication service fails, can users still access cached content?

Strong interview responses address SPOFs proactively: “The load balancer is a potential SPOF, so we’d use redundant load balancers in active-active configuration with health checks. If one fails, DNS or a higher-level load balancer routes traffic to the healthy one.”

Graceful degradation. When components fail, degrade functionality instead of failing completely. If your recommendation engine is down, show popular items instead. If personalization fails, show a generic feed. If image thumbnails fail, show placeholders.

This demonstrates senior judgment: understanding that partial functionality is better than total failure for user-facing services.

Retry Logic & Failure Handling

When to retry. Transient errors (network blips, temporary overload) benefit from retries. Permanent errors (authentication failures, invalid requests) shouldn’t retry. The key is distinguishing between the two.

Exponential backoff with jitter. Don’t retry immediately—wait an increasing amount of time between retries: 1s, 2s, 4s, 8s. Add random jitter to prevent synchronized retry storms where thousands of clients retry simultaneously.

In interviews: “When the database connection fails, we retry with exponential backoff: 100ms, 200ms, 400ms up to 3 attempts. We add random jitter of 0-50ms to prevent thundering herd. After 3 failures, we circuit break and return an error to the client.”

Circuit breakers. After N consecutive failures, stop making requests to the failing service. Check periodically if it’s recovered. This prevents cascading failures and gives the downstream service time to recover.

Timeouts everywhere. Every network call needs a timeout. Without timeouts, a slow downstream service can exhaust your connection pool and bring down your entire application. Set aggressive timeouts (500ms-2s for most services) and handle timeout errors gracefully.

The thundering herd problem. When a popular cache key expires, thousands of requests simultaneously try to regenerate it, overwhelming the database. Solution: lock the cache key during regeneration so only one request does the work. Others wait briefly or return stale data.

Data Consistency & Integrity

Idempotency. Operations that can be repeated safely without changing the result beyond the first execution. Critical for retry logic—if you retry a payment, you don’t want to charge twice. Implement by using unique request IDs and checking if the operation already completed.

Two-phase commit (2PC). Ensures atomicity across multiple databases: prepare phase asks all participants if they can commit, commit phase executes if all agree. Expensive and slow—avoid in high-throughput systems. Modern systems prefer eventual consistency or sagas.

Eventual consistency patterns. When you can’t have strong consistency, design for eventual consistency: acknowledge writes immediately, propagate asynchronously. Handle conflicts through last-write-wins, versioning, or application-level merge logic.

Demonstrate you’ve thought through consistency: “For the shopping cart, we can use eventual consistency. If a user adds an item on their phone and immediately checks on their laptop, seeing it a few seconds later is acceptable. For checkout, we need strong consistency—we use a transaction to verify inventory and create the order.”

Monitoring, Logging & Observability

Metrics. Quantitative measurements: requests per second, error rate, latency percentiles, CPU usage, memory consumption. Aggregate and visualize in dashboards. Alert when thresholds are breached.

Logs. Discrete events with timestamps and context: “User 12345 requested feed at 2024-02-06T10:30:00Z, returned 50 items in 150ms.” Enable debugging specific requests. Expensive to store at scale, so sample or aggregate.

Traces. Follow a single request through multiple services: API gateway → app server → cache → database. Show where time is spent. Critical for distributed systems where a slow request might be caused by any of a dozen services.

In interviews, proactively discuss observability: “We’d instrument this with metrics tracking request latency, error rates, and cache hit rates. Logs would capture errors and slow queries. We’d use distributed tracing to debug latency spikes across services. Alerts would fire if error rate exceeds 1% or p99 latency exceeds 500ms.”

Disaster Recovery & Business Continuity

Backup strategies. Full backups capture everything but are slow and expensive. Incremental backups capture only changes—faster but require full backup to restore. Continuous replication to a standby system enables near-zero data loss.

Recovery objectives. RTO (Recovery Time Objective): how long can you be down? RPO (Recovery Point Objective): how much data can you lose? These drive architecture—if RTO is 5 minutes, you need hot standbys. If RPO is zero, you need synchronous replication.

Multi-region architectures. Active-passive: one region serves traffic, another is standby—simple but wastes resources. Active-active: both regions serve traffic—complex but efficient. Considerations: data consistency across regions, failover mechanisms, routing strategies.

Show you understand the tradeoffs: “For active-passive, we get simpler data consistency but waste half our capacity. For active-active, we need conflict resolution for writes and more complex routing, but we utilize all resources and can handle regional failures without downtime.”

Reliability separates candidates who’ve built toy projects from those who’ve operated production systems. When you proactively discuss failure modes, monitoring, and disaster recovery, you signal senior-level experience. Most candidates wait to be asked—strong candidates design for reliability from the start.

Security & Abuse Prevention (Interview-Ready Version)

Security questions in system design interviews aren’t about implementing encryption algorithms. They’re about demonstrating you think defensively and understand common attack vectors.

Senior candidates proactively mention security when designing APIs, storing data, or handling user input. You don’t need deep security expertise—you need to show security is part of your default thinking.

Authentication vs Authorization

Authentication (AuthN) answers “who are you?” Users prove their identity through passwords, tokens, biometrics, or multi-factor authentication. In interviews, you don’t need to design AuthN from scratch—reference industry standards like OAuth 2.0, JWT tokens, or SAML.

Authorization (AuthZ) answers “what can you do?” Once authenticated, what resources can this user access? Common patterns: role-based access control (RBAC), attribute-based access control (ABAC), access control lists (ACLs).

Interview example: “For authentication, we’d use OAuth 2.0 with JWT tokens. Users authenticate once, receive a signed token valid for 1 hour, and include it in subsequent requests. For authorization, we implement RBAC—users have roles like admin, moderator, or user, and each role has specific permissions.”

Session management. Stateless tokens (JWT) scale horizontally but can’t be revoked instantly. Stateful sessions (server-side storage) allow instant revocation but require shared session state across servers. Most systems use tokens with short expiration plus refresh tokens for long-lived sessions.

API Security Basics

HTTPS everywhere. Encrypt data in transit using TLS. This prevents man-in-the-middle attacks where attackers intercept network traffic. In interviews, stating “all API communication uses HTTPS” is sufficient—you don’t need to explain certificate chains.

API authentication. Require authentication for all non-public endpoints. Use API keys for service-to-service communication. Use OAuth tokens for user-facing APIs. Rotate keys periodically. Never put credentials in URLs or logs.

Input validation. Validate all user input on the server side, never trust client validation. SQL injection, XSS, and command injection all exploit insufficient input validation. Sanitize inputs, use parameterized queries, escape output.

CORS (Cross-Origin Resource Sharing). Controls which domains can make requests to your API. Configure restrictive CORS policies to prevent unauthorized websites from calling your APIs using users’ credentials.

Data Privacy & Protection

Encryption at rest. Sensitive data (passwords, payment info, PII) should be encrypted in databases and backups. Use industry-standard encryption (AES-256). Hash passwords with bcrypt or Argon2, never store plain text.

Encryption in transit. Already covered with HTTPS, but also applies to internal service-to-service communication. Within a private network, encryption might be optional—but increasingly, zero-trust architectures encrypt everything.

PII (Personally Identifiable Information) handling. Know what constitutes PII: names, email addresses, phone numbers, addresses, IP addresses in some jurisdictions. Store minimal PII. Provide mechanisms for users to view, export, and delete their data (GDPR, CCPA compliance).

Data retention policies. Don’t keep data forever. Define retention periods based on business needs and legal requirements. Implement automated deletion. This reduces attack surface and compliance risk.

Threat Modeling (Interview Level)

STRIDE framework. A simple way to think about threats: Spoofing (fake identities), Tampering (data modification), Repudiation (denying actions), Information disclosure (data leaks), Denial of service (availability attacks), Elevation of privilege (unauthorized access).

You don’t need to do formal threat modeling in interviews, but mentioning “I’d consider STRIDE threats: spoofing through weak authentication, tampering through unsigned requests, information disclosure through logs containing PII” shows maturity.

Principle of least privilege. Users and services should have minimal permissions needed to function. Database connections from app servers shouldn’t have DROP TABLE privileges. Service accounts shouldn’t have admin access. This limits damage from compromised credentials.

Defense in depth. Don’t rely on a single security control. Layer multiple defenses: network firewalls, authentication, authorization, input validation, encryption, monitoring. If one layer fails, others protect the system.

Abuse Prevention & Rate Limiting

Common abuse patterns. Credential stuffing (trying stolen passwords), scraping (harvesting data), spam (unwanted content), fake accounts, API abuse (excessive requests), DDoS (overwhelming with traffic).

Rate limiting strategies. Already covered in Chapter 5, but from a security perspective: implement at multiple layers (API gateway, application, database). Use different limits for authenticated vs anonymous users. Implement stricter limits for sensitive operations like login attempts or password resets.

CAPTCHA and bot detection. Use CAPTCHA for suspicious activity: multiple failed login attempts, high-frequency form submissions, unusual access patterns. Modern solutions like reCAPTCHA v3 work invisibly in the background, only challenging suspected bots.

IP-based blocking. Block or throttle requests from IPs with abusive patterns. Maintain blocklists of known bad actors. Use geolocation to block regions if your service doesn’t operate there. But be careful—legitimate users might share IPs (corporate networks, VPNs).

Account lockout policies. After N failed login attempts, temporarily lock the account or require additional verification. This prevents brute-force password attacks. Balance security with usability—too aggressive and you lock out legitimate users who forgot their password.

When Security Questions Come Up

Don’t wait for the interviewer to ask about security. Proactively mention it when relevant: “For the login API, we’d implement rate limiting to prevent brute force attacks and use bcrypt to hash passwords.” “User-uploaded images need validation to prevent malicious files, and we’d store them in isolated S3 buckets.”

If asked to deep dive on security, focus on practical concerns for the specific system. For a payment system, emphasize PCI compliance, encryption, and audit logs. For a social network, emphasize content moderation, privacy controls, and abuse prevention.

You’re not expected to be a security expert—you’re expected to recognize common vulnerabilities and apply industry-standard mitigations. Mentioning OAuth, HTTPS, input validation, and rate limiting covers 80% of security questions.

Performance & Capacity Planning (Numbers Without Panic)

Back-of-the-envelope calculations separate candidates who understand scale from those who just memorize architectures. You don’t need perfect precision—you need to demonstrate quantitative thinking.

The goal isn’t getting exact numbers. It’s showing you can estimate storage, bandwidth, and compute requirements to inform design decisions.

Essential Numbers to Memorize

Memorize these approximate values. You’ll reference them in every capacity estimation.

Data sizes: 1 character = 1 byte. Small text message = 100 bytes. Tweet = 280 bytes. Email = 10KB. Photo (compressed) = 200KB. Photo (high-res) = 2MB. Short video (1 min) = 10MB. Movie (HD, 2 hours) = 4GB.

Request latencies: Memory access = 100 nanoseconds. SSD read = 100 microseconds. Network within datacenter = 500 microseconds. Cross-country network = 50 milliseconds. Database query (simple) = 1-10ms. Database query (complex) = 100ms+.

Throughput: 1 Gbps network = 125 MB/s. High-end server = 10K requests/second. Modern SSD = 500 MB/s read. Database (well-indexed) = 5K queries/second. Database (poorly-indexed) = 100 queries/second.

Scale references: 1 million = 10^6. 1 billion = 10^9. 1 trillion = 10^12. Powers of 2: 2^10 = 1K, 2^20 = 1M, 2^30 = 1B, 2^40 = 1T.

Capacity Estimation Framework

Step 1: Define scale. How many users? Daily active users (DAU)? Monthly active users (MAU)? What’s the ratio of reads to writes? What’s peak vs average traffic?

Example: “Assuming 100M DAU, with each user checking their feed 10 times daily. That’s 1B feed requests per day.”

Step 2: Calculate throughput. Convert daily numbers to per-second. Use 100,000 seconds per day for easy math (actual: 86,400). For peak traffic, multiply by 2-5x depending on usage patterns.

Example: “1B requests / 100K seconds = 10K requests per second average. Peak could be 30K RPS.”

Step 3: Calculate storage. Identify what you’re storing and its size. Multiply by number of items. Add 20-30% overhead for indexes, metadata, replication.

Example: “100M users, each uploads 10 photos/month average. 100M users × 10 photos × 200KB = 200TB monthly. With 3x replication, 600TB monthly. Annually: 7.2PB.”

Step 4: Calculate bandwidth. For reads: requests per second × average response size. For writes: writes per second × data size. Convert to Gbps or MB/s.

Example: “10K feed requests/sec × 500KB average = 5GB/sec = 40 Gbps for reads. Photo uploads: 1M uploads/day = 10 uploads/sec × 200KB = 2MB/sec negligible compared to reads.”

Step 5: Estimate compute resources. Given throughput, how many servers? A modern server handles 1K-10K RPS depending on complexity. For 30K RPS peak, you need 3-30 servers depending on request complexity. Add redundancy and headroom—multiply by 2-3x.

Share this worksheet

Worked Example: News Feed System

Let’s estimate capacity for an Instagram-like news feed system.

Scale assumptions: 500M DAU. Each user checks feed 20 times daily. Each user posts 1 photo every 2 days. Average user follows 200 people.

Throughput calculations: Feed reads: 500M users × 20 views = 10B reads/day = 100K reads/second average, 300K peak. Photo uploads: 500M users × 0.5 uploads/day = 250M uploads/day = 2,500 uploads/second average.

Storage calculations: Photos: 250M/day × 200KB = 50TB daily. With 3x replication = 150TB daily. Annually = 55PB. Metadata (posts, likes, comments): 250M posts/day × 1KB = 250GB daily, negligible compared to photos.

Bandwidth calculations: Feed reads: Each feed shows 20 photos. 100K reads/sec × 20 photos × 200KB = 400GB/sec. But with CDN caching (90% hit rate), origin serves only 40GB/sec. Photo uploads: 2,500 uploads/sec × 200KB = 500MB/sec = 4 Gbps.

Compute estimates: Feed generation is complex (ranking, personalization). Assume 100 RPS per server. Need 3,000 servers for peak traffic. With redundancy and headroom: 5,000+ application servers. Database: With read replicas (10:1 read:write), master handles 5K writes/sec (comfortably), replicas handle 30K reads/sec total.

Design implications: Storage is the dominant cost (55PB annually). CDN is essential—without it, bandwidth costs are prohibitive. Feed generation compute is significant—precomputing feeds (push model) or aggressive caching is necessary. Database reads must be heavily cached to avoid overwhelming replicas.

Notice how capacity estimation directly informs architecture decisions. The numbers aren’t perfect, but they’re defensible and lead to real design insights.

Identifying Performance Bottlenecks

CPU-bound operations. Heavy computation, encryption, video encoding, complex algorithm execution. Solution: more servers, async processing, caching computed results.

Memory-bound operations. Large datasets in memory, caching, session storage. Solution: more RAM, distributed caching, data eviction strategies.

Disk I/O bound operations. Database writes, logging, batch processing. Solution: SSDs instead of HDDs, write-ahead logs, batching, async writes.

Network-bound operations. Large file transfers, chatty protocols, high-latency external APIs. Solution: compression, protocol optimization (HTTP/2, gRPC), CDN, caching, connection pooling.

Database-bound operations. Complex queries, full table scans, missing indexes. Solution: query optimization, proper indexing, denormalization, read replicas, caching.

In interviews, demonstrate you can identify which bottleneck applies: “The main bottleneck here is database reads during feed generation. We’re doing 100+ queries per feed request to gather posts from followed users. Solution: precompute feeds and cache them, reducing database load by 95%.”

Cost-Aware Design

Senior engineers understand that performance has cost tradeoffs. Mentioning cost awareness shows business maturity.

Storage costs: SSDs cost more than HDDs but provide better performance. Replicas multiply storage costs. Frequently accessed data (hot data) goes on expensive fast storage; infrequently accessed (cold data) goes on cheaper slow storage.

Compute costs: Auto-scaling saves money by reducing servers during low traffic but adds complexity. Reserved instances are cheaper than on-demand but require capacity planning. Spot instances are cheapest but can be terminated.

Bandwidth costs: Egress (data leaving cloud providers) is expensive. CDNs reduce origin bandwidth. Compression reduces transfer costs. Keep data in same region when possible.

Database costs: Managed databases (RDS, DynamoDB) cost more but reduce operational overhead. Self-managed databases on EC2 are cheaper but require DBA expertise. Read replicas multiply database costs.

Interview example: “For photo storage, hot photos (recently uploaded, popular content) go on S3 Standard. After 30 days, we transition to S3 Infrequent Access, reducing costs by 50%. After 90 days, to Glacier for 90% cost savings. This tiered storage strategy saves millions annually at Instagram scale.”

Capacity planning isn’t about perfect accuracy—it’s about informed decision-making. When you say “we need 5,000 servers” and can justify that number through calculations, you demonstrate senior-level quantitative thinking. When you identify that storage costs $10M annually and propose tiering strategies to cut that by 60%, you show business awareness.

Practice these calculations until they’re second nature. In interviews, spending 3-4 minutes on capacity estimation sets you apart and grounds your design in reality.

Canonical Practice Designs (With “How to Think” Walkthroughs)

These six problems appear repeatedly in interviews. Master them, and you’ll have mental models for 80% of system design questions.

For each, we’ll cover the problem framing questions you should ask, a sample architecture, common deep dive topics, key tradeoffs, and mistakes to avoid.

Problem 1: URL Shortener (bit.ly, TinyURL)

Problem framing questions: Custom short URLs or auto-generated only? Analytics on clicks? Expected scale? URL expiration? Are we optimizing for write speed or read speed?

Sample requirements: 100M new URLs monthly (40/sec avg, 400/sec peak). 10B redirects monthly (4K/sec avg, 12K/sec peak). Read-heavy system (100:1 ratio). URLs never expire.

One-page architecture: Clients → Load Balancer → App Servers → Redis Cache (LRU, 10GB for hot URLs) → PostgreSQL (URL mappings). Separate write path: App Servers → Message Queue → Analytics Workers → Analytics DB.

Data model: Table url_mappings: short_code (PK, 7 chars), original_url (varchar), created_at (timestamp), user_id (FK, nullable). Index on short_code for O(1) lookups.

Deep dive 1: Short code generation. Requirements: unique, short, unpredictable. Option A: Auto-incrementing counter + base62 encoding. Pro: guaranteed unique. Con: predictable, reveals volume. Option B: Random generation + collision checking. Pro: unpredictable. Con: must check for collisions. With 62^7 = 3.5T possible codes and 100M URLs, collision probability is negligible (<0.003%). Retry on collision.

Deep dive 2: Caching strategy. 80/20 rule: 20% of URLs get 80% of traffic. Cache 10GB = 20M URLs (most popular). Use Redis with LRU eviction. Cache hit rate ~85%. For cache misses, fetch from DB, insert into cache. Cache stampede protection: lock key during DB fetch.

Deep dive 3: Scaling writes. Current: 400 writes/sec peak fits on single DB. Future: shard by hash(short_code) when writes exceed 10K/sec. Each shard handles subset of short codes. Lookup requires routing layer that hashes code and queries correct shard.

Key tradeoffs: Counter vs random generation: predictability vs simplicity. Cache size: larger cache = higher hit rate but more memory cost. Analytics async vs sync: async adds latency to click counts but doesn’t slow redirects.

Common mistakes: Generating short codes client-side (security issue). Not caching (database becomes bottleneck). Using UUIDs for short codes (not short!). Synchronous analytics updates (slows redirects).

Problem 2: News Feed / Timeline (Instagram, Twitter, Facebook)

Problem framing questions: Chronological or algorithmic ranking? Real-time updates or eventual consistency acceptable? Photo/video support? Scale (millions or billions of users)? Average posts per user? Average follows per user?

Sample requirements: 500M DAU. Users follow 200 people average. Each user checks feed 20 times daily. Simple chronological feed (top 100 posts from followed users). Photos included.

One-page architecture: Clients → CDN (photos) → Load Balancer → App Servers → Redis (feed cache) → Feed Service → Cassandra (posts, follows). Photo upload path: Clients → Upload Service → S3 → CDN.

Deep dive 1: Feed generation – Push vs Pull. Pull model: When user requests feed, query database for followed users’ posts, rank, return. Pro: simple, always fresh. Con: slow for users following many people, database-intensive. Push model: When user posts, push to all followers’ pre-computed feeds. Pro: fast reads. Con: writes expensive for celebrities, stale data. Hybrid: Push for regular users, pull for celebrities. Most systems use push with staleness tolerance.

Deep dive 2: Handling celebrities (hotspot problem). Celebrity with 100M followers posts → push to 100M feeds is expensive and slow. Solutions: Don’t pre-push celebrity posts; pull them when users request feeds. Limit feed push to active followers only. Use fan-out queues to batch pushes. Accept some staleness (celebrity posts appear after delay).

Deep dive 3: Photo serving. Store photos in S3 (durable, cheap). Generate multiple sizes (thumbnail, medium, full) on upload. Serve through CDN (Cloudflare, CloudFront) for low latency and reduced origin load. 90%+ requests hit CDN cache. Original URLs expire after 24 hours to prevent hotlinking.

Key tradeoffs: Push vs pull: read speed vs write cost. Feed staleness vs consistency: eventual vs strong consistency. Photo quality vs bandwidth: compression reduces load but degrades quality.

Common mistakes: Fetching posts in real-time from database (too slow). Not caching feeds (database overload). Not handling celebrities specially (celebrity posts break the system). Serving photos from app servers instead of CDN.

Problem 3: Chat / Messaging System (WhatsApp, Slack)

Problem framing questions: One-on-one or group chat? Message history retention? Read receipts? Online/offline status? Media sharing? End-to-end encryption? Scale?

Sample requirements: 100M DAU. Average 50 messages sent per user daily. Support 1-on-1 and group chats (up to 100 members). Message history for 1 year. Real-time delivery when online.

One-page architecture: Clients → WebSocket Gateway (persistent connections) → Message Service → Kafka (message queue) → Storage Service → Cassandra (messages). Separate: Presence Service tracks online/offline status.

Deep dive 1: Real-time message delivery. Use WebSockets for persistent connections. When user sends message, it goes to Message Service → Kafka → routes to recipient’s WebSocket Gateway → pushes to recipient. If recipient offline, store in message queue, deliver when they reconnect. For group chats: fan-out message to all members’ queues.

Deep dive 2: Message storage and retrieval. Store in Cassandra partitioned by chat_id. Each partition stores messages chronologically. For 1-on-1 chats, use hash(user_id_1, user_id_2) as partition key. For groups, use group_id. Queries: “get latest 100 messages for chat_id” are efficient (single partition scan). Index on timestamp for pagination.

Deep dive 3: Presence and online status. Heartbeat model: clients ping Presence Service every 30 seconds while active. Service marks user online. If no heartbeat for 60 seconds, mark offline. Publish status changes to subscribers (friends, group members). Challenge: millions of users × heartbeats creates load. Solution: batch heartbeats, only publish status changes (not every heartbeat).

Key tradeoffs: WebSockets vs polling: persistent connections vs stateless HTTP. Message retention: longer retention = more storage. Read receipts: enable user engagement but require additional tracking. Group size limits: larger groups = more fan-out cost.

Common mistakes: Using HTTP polling instead of WebSockets (inefficient). Not partitioning messages properly (slow queries). Sending presence updates to all users instead of relevant ones. Storing media in message database instead of S3.

Problem 4: Distributed Cache (Memcached, Redis)

Problem framing questions: What are we caching (database query results, session data, API responses)? Expected hit rate? Consistency requirements? Scale? Eviction policy?

Sample requirements: Cache database query results. 10TB cache size. 1M requests per second. Eventual consistency acceptable. LRU eviction.

One-page architecture: App Servers → Consistent Hashing Layer → Cache Cluster (100 Redis nodes, 100GB each). Cache miss → App Server queries Database → populates cache.

Deep dive 1: Consistent hashing. Problem: with simple hash(key) % num_servers, adding/removing servers rehashes most keys. Solution: consistent hashing maps both keys and servers onto a hash ring. Each key goes to the next server clockwise on the ring. Adding a server affects only keys between it and the previous server (~1/N keys). Removing a server affects only its keys. Virtual nodes (each physical server appears multiple times on ring) ensure balanced distribution.

Deep dive 2: Replication and availability. Each cache entry replicated to 2-3 nodes for availability. If a node fails, replica serves requests. Replication strategies: synchronous (consistent but slow) vs asynchronous (fast but might lose recent writes). Most caches use async replication since cache data is transient.

Deep dive 3: Eviction policies. LRU: evict least recently accessed item. Implementation: hash map + doubly-linked list. LFU: evict least frequently used item. FIFO: evict oldest item. TTL: items expire after time period. For database query caching, LRU with TTL is common.

Key tradeoffs: Cache size vs hit rate: larger cache costs more but hits more. Replication vs performance: more replicas = higher availability but more memory. Eviction policy: LRU simple but suboptimal for some patterns.

Common mistakes: Not using consistent hashing (resharding is expensive). No replication (single node failure loses that data). Caching entire query result sets instead of indexed lookups. Not monitoring hit rates.

Problem 5: Rate Limiter

Problem framing questions: User-based, IP-based, or API-key-based limiting? Fixed window or sliding window? Rate limits per second, minute, or hour? What happens when limit exceeded (reject, queue, throttle)?

Sample requirements: Limit users to 100 requests per minute. Distributed system (multiple API servers). Low latency overhead (<1ms). Return 429 status when exceeded.

One-page architecture: Clients → API Gateway (rate limit check) → App Servers. Rate limiter: Redis cluster storing counters per user. Algorithms: token bucket or sliding window log.

Deep dive 1: Token bucket algorithm. Each user has a bucket with N tokens (capacity). Tokens refill at rate R per second. Each request consumes 1 token. If bucket empty, reject request. Implementation in Redis: store token count and last refill timestamp. On each request: calculate tokens to add = (now – last_refill) × R, cap at capacity, subtract 1 for current request. Handles bursts (up to N requests instantly) while enforcing average rate R.

Deep dive 2: Distributed rate limiting. Challenge: multiple API servers checking rate limits must share state. Solution: centralized Redis cluster. Each API server increments user’s counter in Redis before processing request. Race conditions possible but acceptable (slight over-limit tolerated). Alternative: local rate limiters with synchronization, but adds complexity.

Deep dive 3: Handling different rate limits. Different user tiers (free, premium, enterprise) have different limits. Store limits in configuration service. API Gateway fetches user tier, applies corresponding limit. Special paths (login, health checks) might have different or no limits.

Key tradeoffs: Token bucket vs sliding window: burst handling vs strict rate. Local vs distributed: latency vs accuracy. Hard limits vs soft limits: strict enforcement vs grace period.

Common mistakes: Using fixed windows (allows 2x rate at window boundaries). Not handling bursts (users expect some burst capacity). Making rate limit checks synchronous and slow. Not differentiating between user tiers.

Problem 6: File Storage & Sync (Dropbox, Google Drive)

Problem framing questions: File size limits? Versioning? Real-time sync across devices? Sharing and permissions? Deduplication? Scale?

Sample requirements: 50M users. Average 1GB storage per user. Files up to 1GB each. Sync across devices within 1 minute. Version history for 30 days.

One-page architecture: Clients → Upload Service → S3 (file blocks). Metadata Service → Database (file metadata, versions, permissions). Sync Service → WebSockets (notify clients of changes).

Deep dive 1: Chunking and deduplication. Split large files into 4MB blocks. Hash each block (SHA-256). Store blocks in S3 keyed by hash. File metadata stores ordered list of block hashes. Deduplication: if block hash exists, reuse it. This saves storage when users upload same file or same file blocks (common with backups). Reconstruction: fetch blocks by hash, concatenate in order.

Deep dive 2: Sync algorithm. Client maintains local state (file path → hash + modified timestamp). Periodically (or on file change), compares local state with server state. Changes: upload new blocks, update metadata. Server notifies other clients via WebSocket. Other clients fetch changed blocks, reconstruct file. Conflict resolution: last-write-wins or manual merge.

Deep dive 3: Versioning. Each file update creates new version. Store version metadata: version_id, created_at, block_hashes. Old blocks remain in S3 until all versions referencing them are purged. After 30 days, purge old versions, delete unreferenced blocks. This enables rollback and recovery from accidental deletes.

Key tradeoffs: Block size: smaller = better deduplication, larger = less overhead. Sync frequency: real-time = more load, periodic = staleness. Version retention: longer = more storage cost.

Common mistakes: Uploading entire files instead of changed blocks (wasteful bandwidth). Not deduplicating (wastes storage). Synchronous sync (slow user experience). Not handling conflicts (users lose data).

These six problems cover fundamental patterns: short-term caching, long-term storage, real-time communication, write-heavy systems, read-heavy systems, and distributed coordination. Master the thinking process for these, and you can adapt to any interview question.

The key isn’t memorizing these architectures. It’s understanding why each component exists, what alternatives you considered, and what tradeoffs you made. When an interviewer asks “design YouTube,” you’ll recognize it’s similar to the news feed problem (content distribution) plus the file storage problem (video storage) plus the CDN problem (media serving). You’ll combine these patterns into a new solution.

The Mock Interview Loop (How to Improve Fast)

Reading about system design doesn’t make you good at interviews. You need deliberate practice with feedback loops. The mock interview loop is how you transform knowledge into performance.

Most candidates practice wrong. They read about distributed systems, watch YouTube videos, then go into interviews unprepared. The ones who pass practice like athletes: structured reps, measurement, targeted improvement.

The Four-Week Mock Interview System

Week 1: Timed solo practice. Pick a problem from Chapter 9. Set a 45-minute timer. Talk out loud as if an interviewer is present. Record yourself (audio or video). Don’t pause or look things up—simulate real interview conditions. Do this 3-4 times this week with different problems.

Week 2: Self-review and iteration. Watch your recordings. Use the evaluation rubric from Chapter 3. Score yourself honestly on each dimension. Identify your weakest area—is it clarifying requirements? Explaining tradeoffs? Managing time? Do 3-4 more timed reps this week, focusing on your weak area.

Week 3: Peer mock interviews. Find another candidate (online communities, colleagues, friends). Take turns interviewing each other. The interviewer uses the rubric to score and provide feedback. Receiving real-time questions forces you to think on your feet—critical interview skill. Do 2-3 peer mocks this week.

Week 4: Professional mock interviews. Get at least one mock interview from an experienced interviewer—ideally someone who’s conducted real system design interviews at target companies. Services like interviewing.io, Pramp with paid coaches, or SystemDesign.academy’s mock interview program provide calibrated feedback. This shows where you actually stand versus your self-assessment.

Share this system

How to Self-Review Effectively

Watch with the rubric open. Score each dimension 1-5 as you watch. Don’t be generous—rate yourself as an interviewer would. If you skipped requirements gathering, that’s a 1-2, not a 3.

Count your filler words and pauses. “Um,” “like,” “you know,” and long silences hurt your perceived confidence. In one mock, count them. Most candidates are shocked at the frequency. Awareness alone reduces fillers by 50%.

Time each phase. Did you spend 20 minutes on APIs and 5 minutes on architecture? That’s poor time management. Aim for the phase timings in Chapter 4’s framework. Adjust in your next mock.

Check your tradeoff explanations. Every time you made a decision, did you explain alternatives and why you chose this one? Circle every decision point in your transcript. Did you justify it with tradeoffs? If not, that’s your focus area.

List your knowledge gaps. When you said “I’m not sure about sharding strategies” or got stuck explaining consistency models, write it down. These are study topics for this week. Don’t practice more mocks until you’ve filled the gap.

Building Your Weakness Backlog

Create a simple tracking system. After each mock interview, log:

Problem: URL Shortener. Date: Feb 1. Overall score: 3.2/5. Weakest dimension: Scalability (2/5). Specific issue: Couldn’t explain sharding strategy, fumbled consistent hashing. Action item: Study Chapter 5 sharding section, practice explaining consistent hashing aloud, do one more mock with a caching problem.

This backlog prevents random practice. You’re always working on your actual weak points, not what you think you should study.

Pattern recognition. After 5-10 mocks, patterns emerge. Maybe you always struggle with capacity estimation. Or you consistently skip reliability concerns. These aren’t random—they’re skill gaps. Target them with focused study and practice.

The Role of Professional Coaching

Self-study gets you 70% of the way. The last 30%—the difference between passing and failing at competitive companies—requires calibrated feedback from experienced interviewers.

Professional coaching accelerates improvement through:

Accurate calibration. You can’t judge your own performance objectively. An experienced coach tells you exactly where you stand versus the bar for L5 at Google or Staff at Meta. This prevents both overconfidence and unnecessary anxiety.

Targeted feedback. Instead of “work on scalability,” you get “your database sharding explanation was good, but you didn’t consider hot key redistribution, which senior candidates must address.” This specificity saves weeks of unfocused practice.

Company-specific preparation. Different companies emphasize different things. Google wants depth on distributed systems. Amazon wants operational excellence and availability. Meta wants scale and performance. A coach who’s interviewed at these companies guides your preparation accordingly.

Accountability and structure. Weekly coaching sessions force consistent practice. You won’t skip mock interviews when you’re accountable to someone. The structure prevents the common pattern: study for two weeks, get busy, forget everything, cram before interviews.

If you’re interviewing at FAANG or tier-1 companies for senior+ roles, investing in coaching has the highest ROI of any interview prep. The salary difference between passing and failing—easily $50K-100K annually—makes coaching costs negligible.

Our SystemDesign.academy coaching program includes 8 one-on-one mock interviews with senior engineers from Google, Meta, and Amazon, personalized feedback on your designs, and targeted improvement plans. We’ve helped over 2,400 engineers land L5+ offers.

Mock Interview Dos and Don’ts

Do: Simulate real conditions. Use a whiteboard or collaborative doc. Set strict time limits. Don’t pause to look things up. The more realistic your practice, the more prepared you’ll be.

Don’t: Practice without recording. You can’t review what you can’t replay. Even audio recordings are valuable. Watching yourself reveals issues you’d never notice in the moment.

Do: Practice thinking out loud. In real interviews, silence is deadly. Train yourself to verbalize your thought process continuously. “I’m considering two approaches here—let me walk through the tradeoffs.”

Don’t: Memorize solutions. Interviewers ask variations. If you’ve memorized “the Instagram design,” you’ll struggle when they ask for TikTok or Pinterest. Practice the thinking process, not specific answers.

Do: Get comfortable with uncertainty. You won’t know every answer. Practice saying “I haven’t built this exact system, but here’s how I’d approach it based on similar problems” rather than freezing or making things up.

Don’t: Skip the mock interview phase. No amount of reading substitutes for timed practice under pressure. The candidates who pass consistently are the ones who’ve done 20+ mocks before real interviews.

The mock interview loop is where preparation becomes performance. Reading this guide gave you knowledge. Mock interviews give you the muscle memory, confidence, and polish that separate candidates who pass from those who fail.

Study Plans (2/4/8-12 Weeks)

How much time you have determines your strategy. These plans assume you’re working full-time and can dedicate 60-90 minutes daily to preparation.

2-Week Crash Course (Emergency Prep)

You have an interview scheduled in two weeks. This is survival mode—focus on high-impact preparation.

Week 1: Framework and fundamentals.

Days 1-2: Master the eight-phase framework (Chapter 4). Do 2 timed walkthroughs of URL shortener using the framework. Record yourself. Review and identify issues.

Days 3-4: Study core building blocks (Chapter 5): caching, load balancing, databases, sharding. Create quick reference notes for each. Do timed mock: design a rate limiter.

Days 5-6: Study reliability and capacity planning (Chapters 6 & 8). Memorize essential numbers. Do timed mock: design a news feed. Practice capacity estimation.

Day 7: Review all mocks. Identify your weakest area. Spend 90 minutes on focused study of that topic.

Week 2: Practice and refinement.

Days 8-10: One timed mock per day from canonical problems (Chapter 9). Self-review immediately after each. Focus on talking continuously and explaining tradeoffs.

Days 11-12: Get 2 peer mock interviews or 1 professional mock. Implement feedback immediately with one more practice problem.

Days 13-14: Review your weakness backlog. Do targeted study on remaining gaps. Practice one final mock on a problem you haven’t done. Rest the day before your interview—your brain needs recovery.

Key focus for 2-week prep: Master the framework. Know the canonical problems. Practice talking out loud. Don’t try to learn everything—focus on demonstrating structured thinking and communication.

4-Week Comprehensive Prep

Four weeks gives you time to build real competence. This is the sweet spot for most candidates.

Week 1: Foundation and framework.

Monday-Tuesday: Read Chapters 1-3. Understand what interviews test and how you’re evaluated. Do the self-evaluation exercise.

Wednesday-Friday: Master the eight-phase framework (Chapter 4). Do 3 timed mocks: URL shortener, rate limiter, and one other canonical problem. Record and review each.

Weekend: Study core building blocks (Chapter 5). Create a reference sheet with when to use each component and key tradeoffs. Rest Sunday.

Week 2: Deep dives and practice.

Monday-Wednesday: Study reliability (Chapter 6), security (Chapter 7), and capacity planning (Chapter 8). Do practice capacity calculations for 3 different problems.

Thursday-Friday: Timed mocks on news feed and chat system from Chapter 9. Focus on incorporating reliability and capacity estimation into your designs.

Weekend: Review all previous mocks. Update weakness backlog. Study your top 2 weak areas deeply. Rest Sunday.

Week 3: Canonical problems mastery.

Monday-Friday: Do all 6 canonical problems from Chapter 9. One per day, timed, recorded. This is your core practice volume. By the end of week 3, you should be comfortable with the problem-solving pattern.

Weekend: Get 2 peer mock interviews on problems you haven’t practiced. Fresh problems test whether you can apply the framework, not just recall solutions. Review feedback. Rest Sunday.

Week 4: Polish and calibration.

Monday-Tuesday: Address remaining items in weakness backlog. If you struggle with NoSQL databases, study that deeply. If capacity estimation still feels shaky, do 5 more practice calculations.

Wednesday-Thursday: Get 1-2 professional mock interviews. This calibrates you to the actual bar. Implement feedback immediately.

Friday: One final timed mock on a problem you haven’t seen. This tests your readiness. If you score 4+/5 on the rubric, you’re ready.

Weekend: Light review only. Go through your framework notes. Rest well. Your brain needs recovery before interviews.

8-12 Week Deep Mastery

If you have 8-12 weeks, you can achieve genuine mastery. This timeline lets you build deep understanding, not just interview skills.

Weeks 1-2: Foundation phase (same as 4-week plan). Framework, building blocks, initial practice mocks.

Weeks 3-4: Canonical problems (same as 4-week plan). All 6 canonical problems, peer mocks, professional calibration.

Weeks 5-6: Advanced topics deep dives.

Focus areas: Distributed consensus (Raft, Paxos—concepts only). Advanced caching patterns (write-through, write-behind, cache stampede). Database internals (B-trees, LSM trees, compaction). Stream processing (Kafka internals, exactly-once semantics). Microservices patterns (service mesh, circuit breakers, bulkheads).

Practice: 2-3 mocks per week on increasingly complex problems. Design problems you create by combining canonical patterns: “Design Netflix” (video streaming + CDN + recommendation engine). “Design Uber” (geospatial indexing + real-time matching + payment processing).

Weeks 7-8: Company-specific preparation.

Research target companies. Read engineering blogs from your target companies. Understand their technology stack and architectural patterns. Google focuses on scale and distributed systems. Amazon emphasizes operational excellence and cost. Meta wants performance and iteration speed.

Practice company-specific problems. Find Glassdoor or Blind reports of actual interview questions from your target companies. Practice those specific problems. Different companies ask different styles—calibrate accordingly.

Get professional coaching. At this point, invest in 3-4 sessions with coaches who’ve interviewed at your target companies. They’ll calibrate you to the actual bar and identify company-specific gaps.

Weeks 9-10: Volume practice and pattern recognition.

High-volume mocks. Do 10-15 timed mocks in these two weeks. Mix canonical problems with variations. The goal is pattern recognition—you start seeing that most problems are combinations of patterns you know.

Study real-world architectures. Read about how actual companies built their systems: Instagram’s feed ranking, Uber’s geospatial matching, Netflix’s recommendation engine, Discord’s message delivery. These case studies give you concrete examples to reference in interviews.

Weeks 11-12: Polish and readiness.

Final professional mocks. Get 2-3 professional mock interviews. You should be consistently scoring 4-5/5 on the rubric by now. If not, extend your timeline or identify the specific gap.

Review and consolidation. Review all your notes. Ensure you can explain every building block, every canonical problem, every tradeoff from memory. Create a one-page cheat sheet with framework, key numbers, and common patterns.

Mental preparation. By week 12, you’ve done 30+ mock interviews. You know the patterns. Now it’s about confidence and performance under pressure. Practice stress management, sleep well, stay physically active.

With 8-12 weeks of focused preparation, you’ll be in the top 10% of candidates. You won’t just pass interviews—you’ll excel and have multiple offers to choose from.

If you want structured guidance through this process, our 12-week SystemDesign.academy program provides the complete curriculum, weekly coaching sessions, and a cohort of peers for accountability. We’ve refined this curriculum over 3 years with 2,400+ successful students.

Common Myths Debunked

System design interview advice is filled with myths that mislead candidates. Let’s correct the most damaging misconceptions.

Myth 1: “You need to memorize architectures”

The truth: Memorizing “the Twitter design” or “the Netflix design” is useless. Interviewers vary the problem just enough to break memorized solutions. They might ask for Instagram but with real-time stories, or Twitter but for a Chinese market with different regulations.

What to do instead: Learn the fundamental patterns and how to combine them. When you understand why Instagram uses a push model for feeds and when to switch to pull, you can design any feed system. The patterns transfer—the specific architectures don’t.

Myth 2: “You need to have built large-scale systems”

The truth: Most candidates haven’t built systems serving millions of users. Interviewers know this. They’re testing your ability to think through scaling challenges, not your resume of production systems.

What to do instead: Study how large-scale systems work. Read engineering blogs. Understand the principles of sharding, caching, replication. Practice applying these concepts. When you say “I haven’t built a system at this scale, but based on similar problems, I’d approach it this way,” that’s perfectly acceptable.

Myth 3: “More components means a better design”

The truth: Over-engineering is a failure mode. Adding every component you know (message queues, multiple caches, microservices, service mesh) without justification shows you don’t understand tradeoffs. Simple, appropriate solutions are valued over complex, unnecessary ones.

What to do instead: Start simple. Add components only when requirements demand them. Justify each addition: “We need a message queue here because writes are bursty and we want to smooth the load on the database.” If the interviewer wants more complexity, they’ll ask.

Myth 4: “There’s one correct answer”

The truth: System design is about tradeoffs, not right answers. Different approaches optimize for different things. A write-optimized design looks different from a read-optimized one. A cost-conscious design differs from a performance-focused one.

What to do instead: State your assumptions explicitly. “I’m optimizing for read performance over write performance based on the 100:1 read:write ratio.” Then design accordingly. If the interviewer changes assumptions, adapt your design and explain the changes.

Myth 5: “You need deep knowledge of every database and framework”

The truth: Interviewers don’t expect you to know the internals of Cassandra, MongoDB, PostgreSQL, Redis, Kafka, and RabbitMQ. They want you to understand when to use each category: SQL vs NoSQL, queues vs streams, different caching strategies.

What to do instead: Know the categories and their tradeoffs. “I’d use a NoSQL database here for horizontal scalability. Something like Cassandra or DynamoDB would work—the specific choice depends on team expertise and cloud provider.” That level of knowledge is sufficient.

Myth 6: “Only FAANG companies ask system design questions”

The truth: System design interviews are now standard for senior roles at most tech companies, from established enterprises to well-funded startups. If you’re interviewing for senior engineer or above, expect system design rounds.

What to do instead: Prepare for system design interviews regardless of where you’re applying. The skills transfer—good system thinking is valuable everywhere. Even if a company doesn’t have a formal system design round, they’ll ask architectural questions in technical rounds.

Myth 7: “You can wing it if you’re experienced”

The truth: Experience helps, but interviewing is a separate skill. Senior engineers with 15 years of experience fail system design interviews because they don’t practice the interview format. The time pressure, the need to verbalize thinking, the structured evaluation—these require practice.

What to do instead: Respect the format. Even with deep experience, do 10-20 mock interviews before your real ones. Practice thinking out loud, managing time, and explaining tradeoffs clearly. Interview skills rust quickly—practice them.

Share these myths

Myth 8: “You must finish the entire design”

The truth: Interviewers don’t expect you to design every microservice, API endpoint, database table, and error handling path in 45 minutes. That’s impossible. They want to see how you prioritize and where you can go deep.

What to do instead: Cover the high-level architecture in 20-25 minutes. Then deep dive on 2-3 interesting components based on interviewer interest. It’s fine to say “For the sake of time, I’ll assume standard OAuth for authentication and focus on the core data pipeline.” This shows judgment and time management.

Myth 9: “Silence is okay while you think”

The truth: Long silences are interview killers. Interviewers can’t evaluate your thinking if you don’t verbalize it. They might think you’re stuck, don’t know the answer, or can’t communicate. Silence makes them uncomfortable and leads to lower scores.

What to do instead: Think out loud constantly. “I’m considering two approaches here—let me walk through both. Option A would give us better write performance but complicates reads. Option B is simpler but…” Even when you’re unsure, say so: “I’m not certain about the best caching strategy here. Let me think through a few options.” This shows active thinking.

Myth 10: “Study everything equally”

The truth: Not all topics have equal importance or interview probability. Caching, load balancing, and database scaling appear in every interview. Specialized topics like blockchain, ML pipelines, or IoT systems appear rarely and only for specific roles.

What to do instead: Master the fundamentals first (Chapters 4-6). These appear in 90% of interviews. Then study topics relevant to your target role. If you’re interviewing for infrastructure roles, go deep on distributed systems. For product engineering roles, focus on API design and user-facing reliability. Prioritize high-value topics.

These myths persist because they’re repeated in blogs, YouTube videos, and even some interview books. Don’t fall for them. Understanding what interviews actually test—and how to prepare effectively—is how you go from failing to passing.

Tools, Templates & Resources Library

This section consolidates all the practical resources you need for effective preparation. Bookmark this page and return to these tools throughout your study.

System Design Interview Framework Template

What it is: A fillable template that walks you through the eight-phase framework for any system design problem.

How to use it: Print multiple copies or use digitally. Fill one out for each practice problem. After 10-15 completed templates, the framework becomes automatic.

Includes: Requirements checklist, capacity estimation worksheet, architecture diagram space, deep dive prompts, bottleneck analysis section.

Download: Available in PDF format from Chapter 4.

Capacity Planning Calculator

What it is: A structured template for back-of-the-envelope calculations with all conversion factors and formulas.

How to use it: Use for every practice problem to build estimation muscle memory. Fill in scale assumptions, calculate throughput, storage, and bandwidth systematically.

Includes: Conversion factors (100K seconds/day, storage units, bandwidth units), example calculations, common estimation patterns.

Download: Available in PDF format from Chapter 8.

Self-Evaluation Scorecard

What it is: The same rubric interviewers use, adapted for self-assessment after mock interviews.

How to use it: After each recorded mock interview, watch the recording and score yourself on each dimension. Track scores over time to measure improvement.

Includes: 1-5 scale for each evaluation dimension, specific indicators for each score level, space for notes on improvement areas.

Download: Available in PDF format from Chapter 3.

Production Readiness Checklist

What it is: A comprehensive checklist covering reliability, monitoring, security, scalability, and disaster recovery considerations.

How to use it: Reference this during practice problems to ensure you’re covering production concerns that senior candidates must address. Use as a final check before finishing any design.

Includes: 25+ checkboxes across five categories, common mistakes to avoid, senior-level signals to demonstrate.

Download: Available in PDF format from Chapter 6.

Mock Interview Feedback Template

What it is: A structured template for giving and receiving feedback during peer mock interviews.

How to use it: When practicing with peers, use this template to provide actionable feedback. Ensures feedback is specific and helpful rather than vague.

Includes: Rating scale for each dimension, space for specific strengths and weaknesses, overall recommendation, next focus areas.

Download: Available in PDF format from Chapter 10.

Canonical Problems Practice Guide

What it is: Detailed walkthroughs of the six canonical system design problems with common variations and follow-up questions.

How to use it: Use this as your core practice material. Master these six problems and you’ll have mental models for 80% of interview questions.

Includes: Requirements checklists, must-discuss components, interviewer follow-up questions, complexity indicators by level (L4/L5/L6+).

Download: Available in PDF format from Chapter 9.

Share this toolkit

Additional Learning Resources

Recommended books: “Designing Data-Intensive Applications” by Martin Kleppmann (deep technical foundation). “System Design Interview” by Alex Xu (visual interview preparation). “Database Internals” by Alex Petrov (advanced database concepts).

Engineering blogs to follow: Netflix Tech Blog (media streaming, microservices). Uber Engineering (geospatial, real-time systems). Instagram Engineering (feed ranking, photo storage). Discord Engineering (real-time messaging, scaling). AWS Architecture Blog (cloud patterns, best practices).

Online communities: r/cscareerquestions (interview experiences). Blind (company-specific interview intel). SystemDesign.academy community (structured preparation with peers).

Practice platforms: Mock interviews with peers (free but requires finding partners). Pramp (free peer matching). Interviewing.io (paid professional mocks). SystemDesign.academy (comprehensive program with coaching).

These resources complement this guide. Use them strategically based on your preparation timeline and learning style. For 2-week prep, stick to this guide and templates. For 8-12 week prep, add books and engineering blogs for deeper understanding.

When to Consider Structured Coaching

You’ve now learned the complete system design interview framework, the building blocks, the canonical problems, and the practice methodology. For many candidates, self-study with this guide is sufficient to pass interviews.

But some situations benefit significantly from structured coaching. Here’s how to decide if coaching is right for you.

Signs You Would Benefit from Coaching

You’re interviewing at highly competitive companies. If you’re targeting Google L5+, Meta E5+, Amazon L6+, or similar roles at top-tier companies, the bar is calibrated precisely. A small gap in any evaluation dimension can mean rejection. Professional coaching ensures you meet the exact bar these companies require.

You’ve failed system design interviews before. If you’ve been rejected after system design rounds, you likely have specific gaps you can’t identify through self-assessment. An experienced coach can pinpoint exactly what’s holding you back—whether it’s communication, tradeoff analysis, or knowledge gaps.

You have limited time to prepare. If you have only 2-4 weeks before interviews and need to maximize every hour of preparation, coaching provides the fastest path to readiness. A coach eliminates wasted time on low-value topics and focuses you on high-impact areas.

You struggle with communication under pressure. Some engineers have the technical knowledge but struggle to articulate their thinking clearly in timed settings. This is a coachable skill—coaches provide specific techniques for thinking aloud, managing silence, and structuring explanations.

You lack confidence in your readiness. Imposter syndrome affects many candidates, especially those transitioning to senior roles. A professional mock interview gives you objective calibration: you’ll know exactly where you stand and what gaps remain. This confidence (or specific improvement plan) is worth the investment.

What Good Coaching Provides

Calibrated feedback. The most valuable aspect of coaching is accurate calibration. After a mock interview with an experienced coach who’s conducted hundreds of real system design interviews, you’ll know precisely where you stand. They’ll tell you “you’re ready for L5 at Google” or “you need to work on scalability discussions for another two weeks.” This clarity is impossible to get from self-study.

Targeted improvement plans. Generic advice like “study distributed systems” wastes time. Coaches provide specific guidance: “Your caching explanations are strong, but you’re not addressing cache invalidation strategies, which is a L5 expectation. Study write-through vs write-behind patterns, then let’s do another mock focusing on a caching problem.”

Company-specific preparation. Different companies have different emphases. Google probes distributed systems deeply. Amazon focuses on operational excellence and availability. Meta wants performance optimization. Coaches who’ve interviewed at these companies guide your preparation to match company-specific expectations.

Accountability and momentum. Self-study is difficult to sustain. Weekly coaching sessions force consistent practice. You won’t skip mock interviews or procrastinate when you have scheduled sessions. This structure is especially valuable for busy professionals.

Confidence building. After 3-4 professional mock interviews where you see your scores improving, you’ll walk into real interviews with genuine confidence. You’ve proven to yourself (and an objective evaluator) that you can perform at the required level.

What to Look for in a Coaching Program

Coaches with relevant interview experience. Your coach should have conducted system design interviews at companies similar to where you’re applying. Ask about their background. The best coaches are senior engineers who’ve interviewed hundreds of candidates.

Structured curriculum. Avoid coaches who just do ad-hoc mock interviews. Look for programs with a clear curriculum covering the framework, building blocks, and practice problems systematically.

Multiple mock interviews. One mock interview isn’t enough. You need 3-8 sessions to show improvement and get calibrated across different problem types. Look for packages with multiple sessions.

Personalized feedback. Generic scorecards aren’t helpful. You want detailed feedback on your specific performance: “At minute 23, when discussing database options, you should have proactively mentioned the read:write ratio as a decision factor rather than waiting for me to ask.”

Proven track record. Look for programs with verifiable success stories. How many students have they helped? What companies have students joined? What’s the success rate?

Self-Study vs Coaching Decision Framework

Choose self-study if: You have 8+ weeks to prepare. You’re interviewing at less competitive companies (non-FAANG). You’ve never failed a system design interview before. You’re disciplined about consistent practice. You have peers to practice with. Budget is a primary constraint.

Choose coaching if: You have <4 weeks to prepare. You're interviewing at Google/Meta/Amazon/Microsoft or equivalent. You've failed system design rounds before. You need accountability to maintain practice. You want company-specific calibration. The salary increase from passing justifies the investment (typically 10-50x ROI).

Hybrid approach: Many successful candidates use this guide for self-study in weeks 1-2, then add 3-4 coaching sessions in weeks 3-4 for calibration and final polish. This combines the cost-effectiveness of self-study with the precision of professional coaching.

Whatever path you choose, the key is consistent, deliberate practice. This guide gives you everything you need to succeed through self-study. Coaching accelerates the process and provides calibration—but the fundamental work of learning and practicing remains the same.

Your Next Action

If you’ve read this far, you’re serious about passing system design interviews. Don’t let this guide sit in your bookmarks. Take action today:

This week: Do your first timed mock interview. Pick URL shortener from Chapter 9. Set a 45-minute timer. Record yourself. Use the framework from Chapter 4. Review your recording with the rubric from Chapter 3. This single action will show you exactly where you stand and what you need to work on.

This month: Complete 10 timed mock interviews using the canonical problems. Get at least one peer mock and one professional mock. Track your scores. Build your weakness backlog. Study targeted topics to fill gaps.

Before your interviews: Ensure you’ve done 20+ mock interviews. Score yourself 4+/5 on the evaluation rubric. Get professional calibration confirming you’re ready. Walk into interviews confident that you’ve prepared systematically.

System design interviews are learnable. The framework works. Thousands of engineers have used these exact methods to land L5+ offers. Now it’s your turn.

Frequently Asked Questions

How long should I prepare for system design interviews?

It depends on your experience and target companies. For mid-level engineers transitioning to senior roles, plan for 4-8 weeks of focused preparation. If you already have system design experience, 2-4 weeks may suffice. For highly competitive FAANG companies at L6+ levels, invest 8-12 weeks. The key is consistent daily practice (60-90 minutes) rather than cramming.

Do I need to have built large-scale systems to pass these interviews?

No. Interviewers understand most candidates haven’t built systems serving millions of users. They’re testing your ability to think through scaling challenges systematically. Study how large-scale systems work through engineering blogs and books, practice applying those concepts in mock interviews, and be honest about your experience: “I haven’t built this exact system, but based on similar problems, here’s my approach.”

Should I memorize common system designs like Twitter or Instagram?

No. Memorizing specific designs is counterproductive because interviewers will vary the problem enough to break memorized answers. Instead, learn the fundamental patterns (caching strategies, database scaling, message queues, load balancing) and how to combine them. When you understand why Instagram uses a push model for feeds and when to switch to pull, you can design any feed system—not just Instagram.

How many mock interviews should I do before real interviews?

Aim for 20-30 mock interviews minimum. In the first 10, you’re learning the framework and building muscle memory. Mocks 10-20 help you refine communication and time management. Mocks 20-30 build confidence and consistency. Top performers often do 40+ mocks. The candidates who fail typically have done fewer than 10 mocks or none at all. Quality matters too—ensure you’re doing timed, recorded mocks with self-review.

What if I don’t know the answer to a specific question during the interview?

Acknowledge what you don’t know while demonstrating how you’d approach it: “I haven’t implemented consistent hashing before, but here’s my understanding of the problem it solves and how I’d design a solution based on hash functions and ring topology.” This shows intellectual honesty and problem-solving ability. Avoid making up answers or going silent—think out loud about how you’d discover the answer or design around the uncertainty.

Are system design interviews different at different companies?

Yes, emphasis varies by company. Google probes distributed systems depth and expects strong theoretical foundations. Amazon focuses on operational excellence, availability, and cost optimization (they often ask “what’s the estimated cost?”). Meta wants performance and iteration speed. Microsoft emphasizes practical solutions and Azure integration. Research your target company’s engineering blog and Glassdoor interview reports to understand their specific focus, but the fundamental framework remains the same across all companies.

Citations

• https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
• https://systemdesign.academy
• https://netflixtechblog.com
• https://engineering.fb.com
• https://eng.uber.com
• https://instagram-engineering.com
• https://discord.com/blog/engineering
• https://aws.amazon.com/architecture/blog

Content Integrity Note

This guide was written with AI assistance and then edited, fact-checked, and aligned to expert-approved teaching standards by Andrew Williams. Andrew has 10 years of experience coaching senior engineers through system design interviews at FAANG and tier-1 tech companies. Technical concepts, frameworks, and best practices are sourced from established distributed systems literature, engineering blogs from Google, Meta, Amazon, and Microsoft, and real interview experiences from 2,400+ coaching clients. All practical advice has been validated through actual interview outcomes.