System Design Interview Prep

Master a 6-step framework and build two architecture diagrams on Eraser.io.

Introduction

30 Second Summary

Every senior engineering interview eventually lands on the same question: "Design a system that handles millions of users." Most developers freeze because they have never practiced thinking at that scale.

In this project, you will learn a repeatable 6-step framework for answering any system design interview question. You will apply that framework by designing two real systems on Eraser.io: a food delivery platform and a WhatsApp-style chat system.

What You'll Build

A complete system design study guide with two architecture diagrams you create yourself on Eraser.io, covering load balancers, caching, message queues, databases, CDNs, and microservices.

By the end of this project, you'll have:

  • A 6-step interview framework you can apply to any system design question in 45 minutes.
  • A food delivery platform architecture diagram on Eraser.io that demonstrates every core building block (load balancer, cache, message queue, multiple databases, CDN, microservices).
  • A WhatsApp chat system architecture diagram you design independently from scratch as proof you can apply the framework to any problem.
  • Secret Mission: Handle the "Now scale it" curveball by evolving your WhatsApp design to support 2 billion users across multiple regions.

Are there any prerequisites?

You should have basic backend development experience. If you have worked with APIs and databases (SQL or NoSQL), you have everything you need to get started.

Set Up Your Design Workspace

Before you can design a system, you need a canvas to think on. In system design interviews, your thinking happens visually on a whiteboard or diagram tool.

In this step, you will set up Eraser.io as your design workspace and get comfortable with its diagram-as-code feature. This is the same tool you will use throughout the project to draw architecture diagrams.

In this step, get ready to:
  • Create a new file in Eraser.io called "System Design Practice".
  • Explore the diagram-as-code feature and built-in icon library.
  • Draw a warm-up test diagram connecting Client, Server, and Database.
Create a new file in Eraser.io

Every Eraser.io file is a workspace that combines a canvas for diagrams and a note editor for documentation. You will create one file to hold all your system design practice diagrams.

  • Open your browser and navigate to eraser.io.
  • Sign in to your Eraser.io account.
  • On the dashboard, click create file.
  • Name the file System Design Practice.
  • Switch the layout to Canvas so you have the full drawing area visible.

What is an Eraser.io file?

An Eraser file has two parts: a Canvas for visual diagrams and a Note editor for Markdown documentation.

You can toggle between three layouts: Both, Note, or Canvas. For system design practice, you will mostly work on the Canvas.

You should now see an empty canvas ready for diagramming.

Explore the diagram-as-code feature and icon library

Eraser.io lets you create diagrams by writing simple code instead of dragging and dropping boxes. This is faster for system design work because you can describe complex architectures in a few lines.

  • On the canvas, open the insert menu by pressing / on your keyboard.
  • Select Diagram-as-code from the menu.
  • Select Cloud Architecture as the diagram type.
  • A code editor panel opens on the canvas where you type diagram code that Eraser automatically renders into visual boxes and arrows.

What is diagram-as-code?

Instead of manually positioning rectangles and drawing lines, you write short declarative statements. Eraser handles all the layout and styling for you.

The syntax is simple: define nodes by name, add optional properties in square brackets (like icons), and connect them with > arrows. For example, Server [icon: aws-ec2] creates a node labelled Server with an EC2 icon.

Eraser includes 3000+ built-in tech icons covering AWS, GCP, Azure, Kubernetes, and most tech logos. You never need to hunt for icons externally.

Draw your warm-up test diagram

Time to get your hands dirty. You will draw the simplest possible architecture: a client connecting to a server connecting to a database.

  • Clear any placeholder code in the diagram editor.
  • Type the following diagram code into the editor:
// Define nodes
Client
Server
Database [icon: database]

// Define connections
Client > Server > Database

What does this code do?

  • Each line in the nodes section defines a box in your diagram. You can optionally add properties in square brackets, like [icon: database] to display a recognizable icon.
  • The > symbol creates a directional connection (arrow) between nodes. Client > Server > Database means Client connects to Server, which connects to Database.
  • Lines starting with // are comments that help you organize your code. Eraser ignores them when rendering the diagram.
  • You should see three boxes appear on the canvas with arrows flowing from Client to Server to Database.
  • Try clicking on individual nodes in the rendered diagram to see how you can reposition them.

Don't see your diagram rendering?

  • Make sure you selected Cloud Architecture as the diagram type when inserting. Other types (like Sequence Diagram) use different syntax.
  • Check that your node names and connection lines are on separate lines. Putting everything on one line can cause unexpected results.
  • Verify that the > arrow has spaces on both sides (e.g. Client > Server not Client>Server).

Still stuck? Help me troubleshoot my Eraser.io diagram-as-code

✔️ Awesome, I see three connected boxes!

Great work. Your workspace is set up and you have confirmed that diagram-as-code works.

ⓧ I'd like to double check the full code

Here is the complete diagram code that should be in your editor:

// Define nodes
Client
Server
Database [icon: database]

// Define connections
Client > Server > Database

Your workspace is ready. Next up, you will learn what system design actually means and why interviewers test it.

Understand the Big Picture of System Design

Your workspace is ready and you've confirmed the diagram-as-code feature works. Now it's time to step back and understand what system design actually means.

Before you draw any architecture diagram, you need a mental model of what you're doing and why. This step gives you the foundational vocabulary and thinking that every later step builds on.

In this step, get ready to:
  • Understand what system design is and why it matters at scale.
  • Learn the difference between monolith and microservices architectures.
  • Understand the format and expectations of a system design interview.
Understand what system design actually is

System design is the practice of deciding HOW to structure software so it handles millions of users without breaking. It is not about writing code.

It is about choosing the right components, connecting them correctly, and reasoning about what happens when traffic spikes from 100 users to 10 million.

What does a system designer actually decide?

A system designer answers questions like: Where should data live? How do we keep the app fast when a million people hit it at once? What happens if one server crashes?

You're choosing components (databases, caches, queues, load balancers) and connecting them in a way that handles real-world scale. Think of it like designing a city's road system before anyone starts pouring concrete.

Learn the difference between monolith and microservices

Every system starts with a fundamental architecture decision: do you keep everything in one application, or split it into many smaller services?

What is a monolith?

A monolith is one big application that handles everything. Your typical Express or Flask app is a monolith.

All the logic (user auth, orders, payments, notifications) lives in the same codebase and deploys as a single unit. It's simpler to develop and debug, but harder to scale individual pieces independently.

What are microservices?

Microservices break a system into independent services (Order Service, Payment Service, Notification Service) that each do one thing well.

These services communicate over APIs or message queues. You can scale, deploy, and update each service independently. The trade-off is added complexity in communication, monitoring, and deployment.

  • In your System Design Practice file on Eraser.io, insert a new diagram-as-code block below your warm-up diagram by clicking the insert menu (+) and selecting Diagram-as-code, then Cloud Architecture Diagram.
  • Paste the following code to visualise the difference between monolith and microservices:
// Monolith Architecture
Monolith App [icon: server] {
  Auth [icon: lock]
  Orders [icon: shopping-cart]
  Payments [icon: credit-card]
  Notifications [icon: bell]
}
Database [icon: database]

Monolith App > Database

// Microservices Architecture
API Gateway [icon: cloud]
Auth Service [icon: lock]
Order Service [icon: shopping-cart]
Payment Service [icon: credit-card]
Notification Service [icon: bell]
Message Queue [icon: mail]
Users DB [icon: database]
Orders DB [icon: database]

// Define connections
API Gateway > Auth Service, Order Service
Order Service > Message Queue
Message Queue > Payment Service, Notification Service
Auth Service > Users DB
Order Service > Orders DB

What does this diagram show?

The top section shows a monolith: everything lives inside one box and talks to a single database. Simple, but every part scales together and deploys together.

The bottom section shows microservices: each service is its own box with its own database. The API Gateway routes requests, and the message queue lets services communicate without being directly connected.

  • Review the rendered diagram. You should see two distinct architectural patterns side by side: a single grouped box for the monolith and separate connected nodes for the microservices.

Diagram not rendering?

Make sure you selected Cloud Architecture Diagram (not Sequence Diagram or Flow Chart) when inserting the diagram-as-code block.

Check that each node name is unique. Eraser requires distinct names for every node in a diagram.

Help me fix my Eraser.io diagram-as-code rendering issue.

Understand what a system design interview looks like

Now that you know WHAT system design is, you need to understand the arena where you'll demonstrate it.

A system design interview is 45 minutes, typically on a whiteboard or diagramming tool. You drive the conversation. Nobody expects working code.

What do interviewers actually want to see?

They want to see you THINK like an architect. Can you break down a vague problem ("design Uber") into concrete requirements, estimate the scale, pick appropriate components, and reason about trade-offs?

The process matters more than the final diagram. An interviewer would rather see clear thinking with a simpler design than a complex diagram you can't explain.

The number one mistake to avoid

The biggest failure mode in system design interviews is jumping straight to drawing a diagram before clarifying requirements. Always start by asking questions about what the system needs to do, who uses it, and at what scale.

  • Here's a summary of the interview format to keep in mind:
  • Duration: 45 minutes total.
  • Format: you diagram and explain your design on a whiteboard or tool like Eraser.io.
  • Expectation: no working code. Demonstrate that you can reason about scale, pick components, and discuss trade-offs.
  • Who drives: you do. The interviewer gives you a prompt ("Design WhatsApp") and you lead from there.

You now have the big picture: system design is about choosing and connecting components at scale, and interviews test your ability to think through that process out loud. Next up, you'll learn the exact 6-step framework that gives you a repeatable structure for any system design question.

Learn the 6-Step Interview Framework

You now know what system design is and what an interview expects from you. The next question is: how do you actually structure your answer when someone says "Design WhatsApp" and starts a 45-minute timer?

In this step, you'll learn a repeatable 6-step framework that works for any system design question. You'll also learn the quick math (back-of-envelope estimation) that tells you whether your system needs 1 server or 1,000.

In this step, get ready to:
  • Learn the 6-step framework with time allocations for a 45-minute interview.
  • Understand back-of-envelope estimation constants.
  • Practice the estimation template with a worked example.
Learn the 6-step framework

Every great system design answer follows the same skeleton. Different sources call it different names (Alex Xu's 4-step, RESHADED, PEDALS), but they all boil down to six phases with a fixed time budget.

Here is the framework and its time allocation for a standard 45-minute interview:

  • Step 1: Clarify Requirements (5 min). Ask questions. Nail down functional requirements (what the system does) and non-functional requirements (scale, latency, availability).
  • Step 2: Estimate Capacity (5 min). Quick math to figure out QPS, storage, and bandwidth. This tells you what class of architecture you need.
  • Step 3: API Design (5 min). Define the key endpoints or interfaces. This grounds the system in concrete inputs/outputs.
  • Step 4: High-Level Architecture (15 min). Draw the boxes and arrows. This is where the diagram lives.
  • Step 5: Deep Dive (10 min). Pick 1-2 components and explain them in detail. Show you understand the hard parts.
  • Step 6: Trade-offs (5 min). Discuss alternatives and justify your choices. Every design decision has a cost.

Why does the framework start with questions, not diagrams?

Roughly 50% of failed system design interviews trace back to candidates jumping straight to a diagram before clarifying requirements. The interviewer wants to see your process. The final diagram matters less than how you arrived at it.

Always state your assumptions out loud. If you assume 10M daily users, say so. The interviewer can correct you before you build on a wrong foundation.

Understand back-of-envelope estimation

Step 2 of the framework asks you to estimate capacity. You are not solving for precision here. You need order-of-magnitude numbers that tell you whether you are building for one server or a distributed cluster.

Memorise these constants. They come up in nearly every estimation:

  • 1 day ≈ 100K seconds (actual: 86,400). Round up for quick division.
  • Single Redis server: 100K+ QPS (GET/SET operations in memory).
  • Single PostgreSQL server: 5K-10K QPS (simple indexed queries).
  • Peak traffic = 3-5x average for consumer apps.
  • Single server: 10K-50K concurrent connections (with async I/O).

What is the estimation's job?

The estimate picks the architecture class. If your QPS is 500, a single PostgreSQL server handles it easily. If your QPS is 500,000, you need caching, sharding, and likely a CDN.

As a rule of thumb: need more than 50K QPS? You need caching or sharding. Need more than 1 TB storage? You need sharding. Need less than 1ms latency? You need caching. Need 99.99%+ availability? You need multi-region.

Practice the estimation template and document your cheat sheet

Every estimation follows the same four-step template: DAU → QPS → Storage → Bandwidth. Let's walk through a concrete example so you can see the pattern in action.

Imagine you are designing a messaging system with 50 million daily active users, each sending 10 messages per day:

  • Total messages/day = 50M users × 10 messages = 500M messages/day.
  • Average QPS = 500M ÷ 100K seconds = ~6,000 QPS.
  • Peak QPS = 6,000 × 3 = ~18,000 QPS.
  • What does 18K QPS tell us? A single PostgreSQL server maxes out at ~10K QPS. So we need either caching in front of the database or multiple database replicas to handle reads.

The formula to memorise

Average QPS = DAU × requests_per_user_per_day ÷ 86,400 (or just divide by 100K for quick math). Peak QPS = Average QPS × peak_factor (use 3x for consumer apps).

Now let's document this as a cheat sheet you can reference during practice. You'll add this to your Eraser.io file alongside your warm-up diagram.

  • In your System Design Practice file on Eraser.io, click the + button to add a new section (or scroll below your existing diagram).
  • Add the following as your personal system design cheat sheet. Type or paste this into a text/doc section:
# System Design Interview Framework

## The 6 Steps (45 min total)
1. Clarify Requirements (5 min) - Ask questions. Functional + non-functional.
2. Estimate Capacity (5 min) - DAU → QPS → Storage → Bandwidth.
3. API Design (5 min) - Key endpoints with inputs/outputs.
4. High-Level Architecture (15 min) - Draw the boxes and arrows.
5. Deep Dive (10 min) - Pick 1-2 hard parts. Explain in detail.
6. Trade-offs (5 min) - Justify choices. Name alternatives.

## Estimation Constants
- 1 day ≈ 100K seconds (actual: 86,400)
- Redis: 100K+ QPS (in-memory GET/SET)
- PostgreSQL: 5K-10K QPS (indexed queries)
- Peak traffic: 3-5x average (consumer apps)
- Single server: 10K-50K concurrent connections (async I/O)

## Estimation Template
Avg QPS = DAU × requests_per_user / 100K
Peak QPS = Avg QPS × 3 (consumer apps)

## Scaling Thresholds
- >50K QPS → need caching or sharding
- >1 TB storage → need sharding
- <1ms latency → need caching
- >99.99% availability → need multi-region

## Worked Example: Messaging App
- 50M DAU × 10 messages = 500M messages/day
- Avg QPS = 500M / 100K = ~6,000
- Peak QPS = 6,000 × 3 = ~18,000
- Conclusion: single DB won't handle peak → need caching or read replicas

What does this cheat sheet do?

This is your quick-reference card for interviews. The 6 steps keep you on track so you never freeze. The estimation constants let you do capacity math in your head. The scaling thresholds tell you which components to reach for.

You will use this framework in Step 6 (food delivery platform) and Step 7 (WhatsApp design). Every time you practice a new problem, follow these 6 steps in order.

  • Confirm your cheat sheet is saved in your System Design Practice file. You should see the framework, constants, and worked example all visible.

Running out of space in your file?

Eraser.io's free plan supports up to 3 files. If your current file feels cluttered, you can create a separate file called "Cheat Sheet" for your reference notes and keep System Design Practice for diagrams only.

Manual diagram creation is unlimited on the free plan. Only AI-generated diagrams are capped.

Help me organise my Eraser.io files for system design practice.

You now have a structured process for answering any system design question and the mental math to size a system in seconds. Next up, you'll learn the actual building blocks (load balancers, caches, queues) that slot into Step 4 of the framework.

Learn Core Building Blocks: Infrastructure

You now have a framework for structuring your answer and a method for estimating capacity. The next question is: what components do you actually put in the diagram?

System design interviews test whether you know the building blocks that make large-scale systems work. In this step, you'll learn the three infrastructure components that sit between your users and your data: load balancers, scaling strategies, and CDNs.

In this step, get ready to:
  • Learn what a load balancer does and the difference between Layer 4 and Layer 7.
  • Understand horizontal vs vertical scaling and why large systems choose horizontal.
  • Learn how a CDN reduces latency for static content.
Understand the load balancer

When your system has more than one server, something needs to decide which server handles each incoming request. That something is a load balancer.

A load balancer sits between your users and your servers. It distributes incoming requests across multiple server instances so no single machine gets overwhelmed.

What does a load balancer actually do?

Think of it like a restaurant host. When customers arrive, the host seats them at different tables instead of sending everyone to the same waiter. If one waiter calls in sick, the host simply stops seating people at their tables.

A load balancer does the same thing for servers. If one server crashes, traffic automatically routes to healthy ones. Your users never notice.

There are two main types of load balancers, and interviewers love asking about the difference:

  • Layer 4 (network-level) routes traffic based on IP address and port number. It is faster because it doesn't inspect the actual content of the request.
  • Layer 7 (application-level) routes traffic based on the content of the request (URL path, headers, cookies). It is smarter because it can send /api/images to image servers and /api/orders to order servers.

Which tools implement load balancing?

The most common tools you'll reference in interviews are Nginx (open source, Layer 7), AWS ALB (managed, Layer 7), and HAProxy (open source, both Layer 4 and Layer 7).

  • In your System Design Practice file on Eraser.io, add a new section titled "Infrastructure Building Blocks".
  • Document the load balancer: what it does, L4 vs L7, and the three tool names (Nginx, AWS ALB, HAProxy).
Understand horizontal vs vertical scaling

When your system needs to handle more traffic, you have two choices. Understanding the difference between them is one of the most fundamental concepts in system design.

  • Vertical scaling means making one server bigger. More RAM, more CPU, faster disks. It is the simplest approach, but it has a hard ceiling (you can only buy so much hardware) and a single point of failure (if that one server dies, everything goes down).
  • Horizontal scaling means adding more servers. Instead of one powerful machine, you run many smaller ones in parallel. This is what large-scale systems use.

Why does horizontal scaling win at scale?

Horizontal scaling has no ceiling. Need to handle 10x more traffic? Add 10x more servers. One server dies? The others keep running.

The load balancer is what makes horizontal scaling possible. It distributes requests across all your server instances so adding a new server immediately increases your capacity.

Interview shortcut

If an interviewer asks "how would you handle more traffic?", the answer is almost always horizontal scaling behind a load balancer. Vertical scaling is only appropriate for components that are hard to distribute (like a primary database before you shard it).

  • Add horizontal vs vertical scaling to your Infrastructure Building Blocks notes. Include why vertical has a ceiling and why horizontal needs a load balancer.
Understand CDN (Content Delivery Network)

When a user in Tokyo requests an image from a server in Virginia, the data travels across the Pacific Ocean. That physical distance adds latency. A CDN solves this problem by copying your static content to servers around the world.

Static content includes images, videos, CSS files, JavaScript bundles, and any file that doesn't change per-user. The CDN caches these files at edge locations closest to your users.

How much does a CDN improve latency?

Without a CDN, fetching a static asset from a distant server takes around 150ms. With a CDN serving it from a nearby edge location, that drops to under 30ms.

For a food delivery app showing hundreds of restaurant images, that difference means pages load in under a second instead of feeling sluggish.

Which CDN tools should you name in interviews?

CloudFront (AWS), Cloudflare (independent, also does DDoS protection), and Akamai (enterprise, one of the oldest CDNs). Naming any of these shows you know the real-world tooling.

  • Add CDN to your Infrastructure Building Blocks notes. Include what it caches (static content), the latency improvement (~150ms down to <30ms), and the three tool names (CloudFront, Cloudflare, Akamai).
  • Review your complete infrastructure notes. You should have three building blocks documented: Load Balancer, Horizontal vs Vertical Scaling, and CDN.

How these three connect

In almost every system design answer, these three appear together. The CDN handles static content so your servers never even see those requests. The load balancer distributes the remaining dynamic requests across your horizontally scaled servers. Together, they form the first layer of any large-scale architecture.

You now have the infrastructure layer covered. These components handle how traffic reaches your servers. Next up, you'll learn the data layer building blocks: databases, caching, and message queues.

Learn Core Building Blocks: Data Layer

Your infrastructure layer (load balancer, CDN, scaling) handles how traffic reaches your servers. Now you need to understand what happens once the request arrives.

The data layer is where your system stores, retrieves, and moves information. These three building blocks decide how fast your system responds, how much load it can handle, and whether it stays reliable when things go wrong.

In this step, get ready to:
  • Learn when to choose SQL vs NoSQL databases and understand replication and sharding.
  • Understand caching with Redis and the cache-aside pattern.
  • Learn how message queues decouple services and keep APIs fast.
Understand databases: SQL vs NoSQL

Every system needs to persist data somewhere. The first architectural decision you will face in most interviews is choosing between SQL and NoSQL databases.

What are SQL databases?

SQL databases like PostgreSQL and MySQL store data in structured tables with defined relationships. They guarantee ACID compliance (Atomicity, Consistency, Isolation, Durability), which means transactions either fully succeed or fully roll back.

Choose SQL when you need joins between tables and reliable transactions. A single PostgreSQL server handles roughly 5K-10K queries per second for simple indexed reads.

What are NoSQL databases?

NoSQL databases like MongoDB, Cassandra, and DynamoDB store data in flexible schemas (documents, key-value pairs, or wide columns). They are designed for horizontal scaling and high write throughput.

Choose NoSQL when you need massive scale with flexible data shapes and do not need complex joins or strict transactions.

Here is the quick decision guide to use in interviews:

  • "Do I need joins and transactions?" If yes, choose SQL.
  • "Do I need massive scale with flexible schema?" If yes, choose NoSQL.

Two scaling strategies apply to databases specifically:

  • Replication means creating copies of your database for reads. Your primary handles writes and replicas serve read traffic.
  • Sharding means splitting your data across multiple machines for writes. Each shard holds a subset of users or records.
  • Add this to your cheat sheet in Eraser.io. Under your infrastructure building blocks section, create a new heading for "Data Layer" and note the SQL vs NoSQL decision guide.
  • Include the throughput numbers: PostgreSQL handles ~5K-10K QPS for indexed reads. NoSQL databases like Cassandra and DynamoDB are built for higher write throughput through horizontal scaling.
  • Note the replication vs sharding distinction. Replication scales reads. Sharding scales writes.

The interview phrasing that impresses

When you explain your database choice, always state the trade-off explicitly. Say something like: "I chose PostgreSQL here because order data needs ACID transactions for payment correctness. The trade-off is that PostgreSQL does not horizontally scale writes as easily as Cassandra, but at our estimated 350 writes/sec, a single primary with read replicas is sufficient."

Understand caching with Redis

Databases are powerful but slow compared to memory. When the same data gets requested thousands of times per second, hitting the database every time wastes resources and adds latency.

What is caching?

Caching means storing frequently-accessed data in memory (RAM) for lightning-fast reads. Redis is the most common cache in system design. A single Redis node handles ~100K QPS, compared to ~5K-10K QPS on PostgreSQL.

That is a 10-20x improvement in throughput just by putting a cache in front of your database.

The most common caching strategy you will draw in interviews is the cache-aside pattern:

  • The application checks the cache first.
  • If the data is there (cache hit), return it immediately.
  • If the data is not there (cache miss), read from the database.
  • Store the result in the cache for next time, then return it.

What is cache invalidation?

Cache invalidation is deciding when cached data becomes stale. If a user updates their profile in the database but the cache still holds the old version, other users see outdated information.

Common strategies include TTL (time-to-live, where entries expire after a set duration) and write-through (where every write updates both the database and the cache). This is one of the hardest problems in computer science, and naming it in an interview shows maturity.

  • Add the cache-aside pattern to your cheat sheet in Eraser.io. Write it as a flow: App → Check Cache → Hit? Return. Miss? → Read DB → Store in Cache → Return.
  • Note the throughput comparison: Redis ~100K QPS vs PostgreSQL ~5K-10K QPS.
  • Add a reminder that cache invalidation is always worth mentioning as a trade-off when you introduce caching in your design.
Understand message queues

Imagine a user places a food order. The system needs to confirm the order, charge their card, notify the restaurant, and send a push notification. If the API does all of this synchronously, the user waits 3-5 seconds staring at a spinner.

Message queues solve this by decoupling the "accept the request" step from the "process everything" step.

What is a message queue?

A message queue sits between producers (the services that create work) and consumers (the services that do the work). The API says "order received!" instantly to the user, then drops a message into the queue. A separate worker picks it up and processes it.

Common tools are Kafka (100K-500K messages/second per broker), RabbitMQ, and AWS SQS.

There are three key benefits to highlight in an interview:

  • The API stays fast. The user gets an instant response because the heavy processing happens in the background.
  • Retry on failure. If a worker crashes, the message stays in the queue and gets picked up again. No work is lost.
  • Independent scaling. You can add more workers when the queue backs up without touching the API servers at all.
  • Add message queues to your cheat sheet in Eraser.io. Note the three benefits: decouple, retry, scale workers.
  • Write a one-line example flow: User places order → API responds instantly → Message dropped in queue → Worker processes (charge card, notify restaurant, send push notification).
  • Include the Kafka throughput number (100K-500K messages/second per broker) as an estimation reference.

When should I reach for a message queue?

Any time you see "async processing" in your requirements, a message queue is the answer. Common triggers: sending emails, processing payments, generating reports, syncing data between services, and handling notifications.

You now have the full toolkit of system design building blocks. Next up, you will put all of them together by designing a complete food delivery platform from scratch.

Design a Food Delivery Platform

You now have a full toolkit of system design building blocks. The real skill is knowing how to combine them into a coherent architecture that solves a specific problem at scale.

In this step, you will apply the 6-step framework end-to-end to design a food delivery platform (think Zomato or Uber Eats). This worked example ties together every concept from the previous steps into one production-style architecture diagram.

In this step, get ready to:
  • Clarify requirements, estimate capacity, and define APIs for the platform.
  • Draw the full high-level architecture on Eraser.io using diagram-as-code.
  • Deep dive into the order processing flow and discuss trade-offs.
Clarify requirements, estimate capacity, and define APIs

Before touching a diagram, you need to answer three questions: what does the system do, how much traffic will it handle, and what endpoints does it expose? This is Steps 1-3 of the framework in action.

Imagine you are in the interview. The interviewer says: "Design a food delivery platform." Your first move is to scope the problem by listing functional requirements.

  • Write these three core requirements in your cheat sheet notes:
  • Users can browse nearby restaurants and view menus.
  • Users can place orders and pay.
  • Users can track their delivery in real-time.

Why clarify requirements first?

About 50% of failed system design interviews trace back to jumping straight to a diagram before clarifying what the system actually needs to do. Spending the first 5 minutes on requirements saves you from designing the wrong thing.

Now run the estimation step. This tells you whether your system needs 1 server or 1000. You are going for order-of-magnitude accuracy, not precision.

  • Add these numbers to your cheat sheet:
  • DAU: 5 million users.
  • Orders per day: 5M users x 2 orders/user = 10M orders/day.
  • Average QPS: 10M / 86,400 seconds = ~115 orders/sec.
  • Peak QPS: 115 x 3 = ~350 orders/sec.

What do these numbers tell you?

At ~350 QPS peak, a single PostgreSQL instance (5K-10K QPS for simple queries) can comfortably handle order writes. You do not need sharding yet.

But you do need caching for read-heavy data (restaurant menus) and a message queue to keep the API fast when processing orders asynchronously.

Finally, define the core API endpoints. In an interview, pick the 3-5 most important ones that show you understand the system's core functionality.

  • Write these three core API endpoints in your cheat sheet:
  • `GET /restaurants` returns a list of nearby restaurants with menus.
  • `POST /orders` creates a new order (items, payment info, delivery address).
  • `GET /orders/:id/track` returns real-time delivery status and driver location.

API design in interviews

You do not need to design every endpoint. The interviewer wants to see you think about inputs, outputs, and who calls what. Three well-chosen endpoints demonstrate more design thinking than ten vague ones.

Draw the high-level architecture on Eraser.io

Now you move to Step 4 of the framework: the actual architecture diagram. This is where you put all the building blocks together into a connected system.

  • Switch to your Eraser.io file and click the + button to open the insert menu.
  • Select Diagram-as-code, then choose Cloud architecture diagram.
  • Paste the following diagram code into the code editor:
// Food Delivery Platform - High-Level Architecture

// Client layer
Client Apps [icon: smartphone]

// Edge layer
CDN [icon: cloudflare]
Load Balancer [icon: load-balancer]
API Gateway [icon: aws-api-gateway]

// Microservices layer
Services {
  Restaurant Service [icon: server]
  Order Service [icon: server]
  Delivery Service [icon: server]
  Notification Service [icon: server]
}

// Data layer
Databases {
  PostgreSQL [icon: postgres]
  Redis Cache [icon: redis]
  MongoDB [icon: mongodb]
}

// Messaging layer
Message Queue [icon: kafka]

// Connections
Client Apps > CDN: static assets
Client Apps > Load Balancer: API requests
Load Balancer > API Gateway
API Gateway > Restaurant Service, Order Service, Delivery Service, Notification Service
Restaurant Service > Redis Cache: menu reads
Order Service > PostgreSQL: order writes
Delivery Service > MongoDB: driver locations
Order Service > Message Queue: order events
Message Queue > Restaurant Service, Delivery Service, Notification Service

What does this diagram represent?

Each layer solves a specific problem. The CDN serves food images fast from the nearest location. The Load Balancer distributes API requests across multiple server instances so no single server gets overwhelmed.

The API Gateway routes requests to the correct microservice. Each microservice owns its domain: restaurants, orders, delivery, or notifications. The data layer uses three different databases because each has strengths for a specific workload.

The Message Queue decouples the services so they can communicate asynchronously without waiting for each other.

  • Click outside the code editor to render the diagram.
  • You should see a clean architecture diagram with icons for each component and labeled arrows showing how data flows through the system.

Diagram not rendering?

Make sure you selected Cloud architecture diagram as the diagram type (not Flow chart or Sequence diagram). The syntax is different for each type.

If you see a syntax error, check that node names with spaces are used consistently in the connections section. For example, Client Apps in the node definition must match Client Apps exactly in the connections.

help me fix my Eraser.io diagram code

Deep dive into order processing and discuss trade-offs

Steps 5 and 6 of the framework are where you prove depth. You pick one critical flow and walk through exactly how data moves through the system, then justify your technology choices.

In an interview, you would narrate this flow while pointing at your diagram. Practice saying it out loud.

  • Add this order processing flow to your cheat sheet notes as a numbered sequence:
  • User places an order via the client app.
  • Request hits the Load Balancer, then the API Gateway routes it to the Order Service.
  • Order Service creates the order in PostgreSQL (ACID transaction ensures payment is recorded correctly).
  • Order Service publishes an OrderCreated event to the Message Queue.
  • Restaurant Service picks up the event and notifies the restaurant.
  • Once the restaurant accepts, Delivery Service assigns the nearest available driver.
  • Notification Service sends real-time updates to the user via WebSocket.

Why does this flow use a message queue?

The Order Service responds to the user immediately after writing to the database. It does not wait for the restaurant to be notified or a driver to be assigned. The message queue handles all of that asynchronously.

This keeps the API response fast and means if the notification system crashes, the order message stays in the queue and gets retried automatically.

Every technology choice has a trade-off. In an interview, proactively explaining WHY you chose something scores higher than just naming the component.

  • Add these trade-off notes to your cheat sheet:
  • Why PostgreSQL for orders and users? You need ACID transactions for payments. If a payment fails mid-transaction, the database rolls it back cleanly. NoSQL databases sacrifice this consistency guarantee.
  • Why MongoDB for driver locations? Drivers send GPS pings every few seconds. MongoDB handles frequent writes efficiently, supports native geo-queries (find drivers within 2km), and does not need the complex joins that a relational database provides.
  • Why Redis for restaurant menus? Menus rarely change but get read thousands of times per second. A single Redis node handles 100K+ QPS, compared to 5K-10K on PostgreSQL. The cache-aside pattern checks Redis first, falls back to the database on a miss.

The trade-off template for interviews

Use this pattern: "I chose [technology] for [data type] because [specific requirement]. The alternative would be [other option], but it falls short because [specific weakness for this use case]."

This shows you weighed options rather than just memorised a stack. Interviewers want to see reasoning, not recitation.

You have just designed a complete food delivery platform using the 6-step framework. You clarified requirements, estimated scale, defined APIs, drew the architecture, traced a critical flow, and justified every technology choice. Next up, you will prove you can do this independently by designing WhatsApp from scratch.

Design a WhatsApp Chat System

Your food delivery platform covered every major building block in system design. You now have hands-on experience applying the 6-step framework from requirements all the way through trade-offs.

Now it is time to prove you can do it without guidance. In this step, you will design a WhatsApp-style chat system entirely on your own, using the same framework you just practised.

In this step, get ready to:
  • Apply the 6-step framework independently to a WhatsApp-style chat system.
  • Draw a complete architecture diagram on Eraser.io.
  • Self-assess your design against a professional checklist.
Understand your design brief

Every system design interview starts with a prompt. Here is yours.

Your interview prompt

Design a chat system like WhatsApp.

Requirements: 1-on-1 messaging, group chats (up to 256 members), online/offline status, message delivery receipts (sent, delivered, read), and media sharing (images, videos).

Scale: 50M DAU, 10 messages per user per day.

Before you touch Eraser.io, run through Steps 1-3 of the framework: Clarify, Estimate, and API Design. Here is the estimation worked out for you.

  • 50M DAU x 10 messages/day = 500M messages/day.
  • Average QPS: 500M / 86,400 seconds ≈ ~6,000 QPS.
  • Peak QPS (3x average): ~18,000 QPS.
  • Concurrent connections: if 30% of DAU are online at once, that is 15M simultaneous WebSocket connections.
  • At ~10K connections per server, you need approximately 1,500 WebSocket servers.

Add these numbers to your cheat sheet

Write the WhatsApp estimation into your System Design Cheat Sheet alongside the food delivery numbers. Having two worked examples makes the estimation template feel second nature in an interview.

Draw your architecture on Eraser.io

This is the real test. You are going to design the high-level architecture yourself, just like you would on an interview whiteboard.

  • Switch back to your System Design Practice file in Eraser.io.
  • Create a new diagram section for your WhatsApp architecture (below your food delivery diagram).

As you draw, think through these guiding questions:

  • How do messages get delivered in real-time? (What kind of connection stays open between client and server?)
  • Where do you store messages permanently?
  • What happens when the recipient is offline? (How do you make sure they still receive the message later?)
  • How do you handle media files (images, videos) differently from text messages?
  • How do you know if a user is online or offline?

Give yourself 15-20 minutes to draw before checking the worked solution below.

✔️ I'll try it first

Go for it. Use the same building blocks you learned (load balancer, cache, queue, databases, object storage) and arrange them for a chat system. Remember: there is no single "correct" answer in system design. What matters is that you can justify every choice.

ⓧ Let me check my work

Here is a complete worked architecture you can compare against. Your diagram does not need to match this exactly. If you covered the same major components and can explain your reasoning, you are on the right track.

High-level flow:

  • Clients (mobile/web apps) open persistent WebSocket connections to the server.
  • Load Balancer sits in front and distributes connections across multiple WebSocket Servers.
  • WebSocket Servers maintain the persistent connections. Each server tracks which users are connected to it.
  • Message Queue (e.g. Kafka) sits between the WebSocket servers and the processing layer. When User A sends a message, the WebSocket server publishes it to the queue. This guarantees delivery even if downstream services are temporarily unavailable.
  • Message DB stores every message permanently. A NoSQL database (like Cassandra or HBase) works well here because chat data is write-heavy, append-only, and rarely updated.
  • Cache (Redis) stores recent conversations and user session data for fast lookups. When a user opens the app, their last 50 messages load from cache instead of the database.
  • Object Storage (S3) handles media separately. Images and videos are uploaded to S3. The message itself only stores a URL pointing to the media file.
  • Presence Service (backed by Redis with TTL-based heartbeats) tracks who is online. Each client sends a heartbeat every few seconds. If the heartbeat stops, the user is marked offline.

Offline delivery (store-and-forward):

  • When User B is offline, the message gets stored in the Message DB and marked as "pending".
  • When User B reconnects, the server pulls all pending messages from the DB and pushes them through the new WebSocket connection.
  • Delivery receipts update as each stage completes: "sent" when the queue accepts it, "delivered" when User B's device receives it, "read" when User B opens the conversation.

Key trade-offs to note:

  • WebSockets over HTTP polling: chat needs instant delivery. Polling introduces latency and wastes bandwidth.
  • NoSQL over SQL for messages: write-heavy, no complex joins needed, horizontal scaling is critical at 18K QPS peak.
  • Separate media path: storing binary blobs in the message DB would destroy throughput. S3 is purpose-built for large objects.

Why WebSockets instead of HTTP polling?

HTTP polling means the client asks "any new messages?" every few seconds. This wastes bandwidth and adds latency (you only get messages at the next poll interval).

WebSockets keep a persistent connection open. The server pushes new messages to the client the instant they arrive. This is what makes chat feel instant.

Self-assess your design

In an interview, the interviewer evaluates whether you covered the critical components. Run through this checklist yourself.

  • A way to maintain persistent connections (WebSocket servers).
  • A message queue for reliable delivery.
  • A database for message persistence.
  • A caching layer (e.g. Redis for recent messages and sessions).
  • A Load Balancer in front of your WebSocket servers.
  • A strategy for offline users (store-and-forward).
  • A separate path for media (object storage like S3).

What if I missed some components?

That is completely normal. The point of this exercise is to discover your gaps before the real interview. Go back to your diagram and add any missing components now.

In a real interview, the interviewer might prompt you with "What happens if the user is offline?" or "How do you handle images?" Those prompts are hints to add the store-and-forward pattern or the S3 media path.

  • Update your System Design Cheat Sheet with the WhatsApp key decisions: WebSockets for real-time, store-and-forward for offline, S3 for media, Redis for presence.

Interview confidence check

If you can explain WHY you chose each component (not just WHAT it does), you are ready for the interview. Practice saying it out loud: "I chose WebSockets because chat requires instant delivery, and polling adds unacceptable latency."

Secret mission

Now Scale It to 2 Billion Users

You just designed WhatsApp for 50 million users. But in a real interview, the interviewer leans forward and says: "Now scale it to 2 billion." This is the curveball that separates senior engineers from staff engineers. Can you evolve your architecture to handle the entire planet?

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely on Eraser.io's free plan, so there are no ongoing costs. Your diagrams and notes will stay in your Eraser.io workspace indefinitely unless you choose to remove them.

Decide whether to keep your resources for future study, or delete them to free up file slots on your free plan.

Resources you used:

  • Eraser.io System Design Practice file (warm-up diagram, Architecture Diagram #1, Architecture Diagram #2, and scaled Architecture Diagram #2).
  • System Design Cheat Sheet (6-step framework, estimation constants, building blocks reference).

Keep everything running

No action needed. Choose this if you want to keep your diagrams as study material or portfolio pieces.

  • Your Eraser.io free plan has no ongoing charges.
  • Your diagrams and cheat sheet remain accessible anytime you sign back in.
  • The free plan supports up to 3 files total, so keep in mind you have limited slots for future projects.

Pause - I'll come back to this later

Since this project has no running processes or paid resources, pausing is the same as keeping. Your files will remain in your Eraser.io workspace at no cost.

  • Your diagrams stay saved and editable whenever you return.
  • Consider bookmarking your Eraser.io workspace URL so you can find your files quickly later.

Delete - I don't want to use this again

Remove your project files to free up file slots on your Eraser.io free plan. This cannot be undone.

  • Open your Eraser.io workspace where your files are listed.
  • Select the System Design Practice file and delete it.
  • If your System Design Cheat Sheet is a separate file, delete that as well.
  • Your Eraser.io account itself remains active. The free plan has no charges, so there is no need to delete your account.

Nice Work!

Nice Work!

Nice work! You now think like a systems architect.

You've gone from learning concepts to drawing complete architecture diagrams that you can walk any interviewer through with confidence.

You've learned how to:

  • Apply a 6-step system design interview framework (Clarify, Estimate, API, Architecture, Deep Dive, Trade-offs) to break down any complex system into a structured 45-minute whiteboard session.
  • Design a complete food delivery platform architecture on Eraser.io, connecting load balancers, caching, message queues, microservices, and multiple database types into one working system.
  • Independently design a WhatsApp-style chat system from scratch, proving you can apply the framework to any system design question.
  • Scale your WhatsApp architecture to 2 billion users with multi-region deployment, database sharding, and geo-routing DNS.

Ready to quiz yourself?