# Capstone: Design the QuickBite Platform

Course: [High-Level Design](https://www.devtutorials.ai/learn/system-design/hld) · Section: HLD Case Studies
Source: https://www.devtutorials.ai/learn/system-design/hld/case-studies/capstone

> Design the whole QuickBite order platform yourself: requirements, per-flow estimates, choosing parts, passing every check, and writing down trade-offs.

This is the final case study, and unlike the previous lessons, there is no single component to focus on. Instead, you design an entire platform by combining everything you have learned throughout the course.

Imagine receiving the following prompt in a design interview or on your first day working on a real product: **Design the QuickBite order platform.** Customers browse menus with photos, place and pay for orders, and track their rider on a map until the food arrives.

At this point, there is no new technology to learn. You already know how to use caching, CDNs, queues, payments, notifications, object storage and in-memory systems. The challenge is deciding when to use each one and explaining why.

**The main idea:** follow the same design process you learned in the first lesson. Start with requirements, estimate the workload, design the system, test the design and document the trade-offs. Let the numbers guide the design instead of relying on habit.

## What You Will Do

In this capstone, you will:

1. Define the requirements for the entire platform.
2. Estimate traffic for menus, photos, orders and rider tracking.
3. Select the right design for each part of the system.
4. Build a complete architecture and validate it.
5. Identify trade-offs and discuss how the system would grow in the future.

This lesson combines ideas from every previous case study, including caching, queues, payments, notifications, file storage, object storage, CDNs and real-time systems.

## Step 1: Requirements

Start the same way as every design.

Before drawing any architecture diagrams, decide what the platform must do and how well it must do it.

### What It Must Do (Functional)

- Allow customers to browse nearby restaurants.
- Display menus and dish photos.
- Allow customers to add items to a cart and place orders.
- Process payments safely.
- Show order progress.
- Display rider locations on a map.
- Send notifications through push messages and SMS.

### How Well It Must Do It (Non-Functional)

- App operations should complete with p99 latency under 150 ms.
- Orders must never be lost.
- Customers must never be charged twice.
- Orders should be confirmed within 3 seconds.
- The platform should continue operating even if one machine fails.
- Infrastructure costs should stay within budget.

### Out of Scope

This capstone focuses only on the customer experience.

The following systems are not included:

- Restaurant applications
- Rider applications
- Recommendation systems
- Search systems
- Restaurant payouts

Each of these could become its own system design project.

## Step 2: Estimate Each Part

One of the biggest lessons in system design is that not all traffic is the same.

Different types of requests have different requirements.

The chart compares the four kinds of traffic at peak:

What to notice:

- Photos create most of the traffic.
- Orders are only a small percentage of requests.
- Different traffic types need different designs.
- The money-making flow is not the biggest flow.

Rider locations are a different shape of traffic. There are 40,000 riders online, each sends a location every 5 seconds, and each location is 64 bytes. Step through where those writes should go:

| Rider locations | Value |
|---|---|
| Location writes | 40,000 ÷ 5 = **8,000 a second** |
| Memory for every rider's latest position | 40,000 × 64 bytes = **2.56 MB** |

What to notice:

- Rider locations create many writes.
- Only the latest location matters.
- All rider locations fit comfortably in memory.
- This makes an in-memory store a better choice than a database.

## Step 3: Choose a Design for Each Part

Choose the simplest design that matches each workload.

| Part | Design | Why |
|---|---|---|
| Menu views | Cache-first reads, database on cache miss | Menus are read often and change rarely |
| Photos | Object storage behind a CDN | Photos are large files and create most traffic |
| Orders and payments | Queue and background workers | Payments are slow and must be reliable |
| Rider locations | In-memory cache | Only the latest location matters |
| Every tier | At least two copies | Survive failures |

Step through the menu read path to see how much reaches the database:

| Cache | Hit ratio | Database reads a second |
|---|---|---|
| 1 cache node | 90% | 600 |
| 2 cache nodes | 95% | 300 |

Next, size the app servers for a failure. Photos go to the CDN, so the app servers carry menus, orders and locations: 6,000 + 300 + 8,000 = 14,300 requests a second. One server handles 4,000. The chart shows how busy the rest are after one server is lost:

What to notice:

- Four servers are not enough during a failure.
- Five servers leave spare capacity.
- Systems should be sized for failures, not only for normal traffic.

Last, check the cost against the $2,000 budget:

| Part | Count | Price each a month | Cost |
|---|---|---|---|
| Load balancers | 2 | $50 | $100 |
| App servers | 5 | $80 | $400 |
| Cache nodes | 2 | $120 | $240 |
| Database copies | 2 | $300 | $600 |
| CDN | 1 | $200 | $200 |
| Object storage | 1 | $100 | $100 |
| Queue | 1 | $60 | $60 |
| Order workers | 2 | $60 | $120 |
| **Total** | | | **$1,820 (budget $2,000)** |

Check the cost before you build. If a design exceeds the budget, it is better to find out early.

## Step 4: Build the System and Validate It

Open the **design sandbox**.

The starting design includes:

- 1 load balancer
- 4 app servers
- 1 database copy
- Object storage
- Direct calls to payment and notification providers

All traffic types arrive at the same time.

| Check | Passes when |
|---|---|
| Peak load | p99 under 150 ms, under 0.1% errors and orders confirmed within 3 seconds |
| Lose any one machine | Under 1% errors, p99 under 300 ms and orders within 5 seconds |
| Cost | At most $2,000 a month |
| Requirements | Orders are processed through a queue and workers |

Build your own design.

Run the checks after each change and see what becomes the bottleneck.

What you will probably find:

- Without a CDN, photo downloads overload the application servers.
- Without a cache, rider location updates overload the database.
- One cache node becomes a single point of failure.
- Four app servers are not enough during failures.

A design that passes:

- 2 load balancers
- 5 app servers
- 2 cache nodes
- 2 database copies
- CDN
- Object storage
- Queue
- 2 order workers

This design costs about **$1,820 per month**, keeps p99 around **36 ms**, and confirms orders in about **1.3 seconds**.

Passing the checks does not mean the design is perfect. Always ask what happens if traffic doubles, costs increase or another service fails.

## Step 5: Understand the Trade-Offs

Every design has trade-offs.

For this design:

- **Rider locations stay in memory:** fast and cheap, but the latest locations may disappear if a cache node fails.
- **Payments run in the background:** safer and more reliable, but users may briefly see a "processing" status.
- **One database leader:** simple today, but orders may need partitioning as traffic grows.
- **CDN for photos:** reduces bandwidth costs, but updated photos should use new file names to avoid stale caches.

## Common Mistakes

| Mistake | Wrong | Correct | Why it happens |
|---|---|---|---|
| Starting with architecture | Draw boxes immediately | Start with requirements and estimates | Architecture is the most visible part |
| Treating all requests the same | Use one design for every workload | Design each workload separately | Simpler diagrams look attractive |
| Rider locations in the database | Thousands of writes per second | Store latest positions in memory | Databases feel like the default choice |
| Ignoring costs | Focus only on performance | Balance cost and performance | Costs are easy to overlook |
| Stopping after checks pass | Assume the design is finished | Document trade-offs and future limits | Passing checks feels like the finish line |

## Practice

## What to Remember

- Follow the design loop: **Requirements → Estimates → Design → Validation → Trade-Offs**.
- Estimate each workload separately.
- The biggest traffic flow is not always the most important one.
- Use cache-first designs for read-heavy workloads.
- Deliver files through object storage and CDNs.
- Use queues for slow or unreliable work.
- Store live data in memory.
- Build for failures from the beginning.
- Estimate costs early.
- Document assumptions, trade-offs and future scaling plans.

Congratulations. You have completed the High-Level Design tutorial. Keep the [HLD Cheat Sheet](/learn/system-design/hld/case-studies/hld-cheat-sheet) handy.

The technologies may change, but the design process stays the same. Strong system design comes from understanding requirements, using data for decisions and clearly explaining trade-offs.

## Further Reading

These are the sources this lesson was checked against:

- [System Design Primer](https://github.com/donnemartin/system-design-primer): a broad collection of design topics and worked examples.
- [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html): reliability, cost and performance as review questions.
- [Google SRE Book: Introduction](https://sre.google/sre-book/introduction/): why reliability, limits and trade-offs are part of design, not an afterthought.