You can learn System Design while waiting for your coffee.

A coffee shop operates like a Distributed System; You will learn how below.

Most engineers think system design is something you only learn from diagrams and textbooks.

But you’ve already used a distributed system this week when you ordered coffee.

Even a coffee shop mirrors core principles of system design: APIs, queues, event-driven processing, bottlenecks, notifications, and more.

Let’s walk through it, step by step.

---

Your Code Can Shape the Future of AI; and Pay Up to $50/hr

Outlier is hiring top software engineers to help improve the world’s leading AI models.

It’s freelance, flexible, and remote.

👉 Review and critique AI-generated code.
👉 Use your expertise to raise the bar on code quality.
👉 No AI experience needed—just solid engineering skills.

If you’ve built real systems, know your way around Git, and love clean code, this is the smartest side hustle you’ll find.

---

1. The Cashier = API Gateway

The cashier is the system’s entry point.

You place a request:

“One oat milk cappuccino, no sugar.”

The cashier validates it, logs it, and returns a response:

“You’re order #37. Please wait to be called.”

That’s exactly how an API works:

• Takes in a structured request.

• Validates and transforms it.

• Sends back an acknowledgment (order ID).

This is synchronous, stateless, and isolated from the backend work.

📌 Design Insight: APIs should validate and log input early, then hand off work to background processes.

2. The Order Queue = Message Queue

Once your order is accepted, it goes into a queue for preparation.
Orders are processed in first-in, first-out (FIFO) order.

But here’s the catch:
Even if orders arrive in order, processing time varies.

A black coffee takes 1 minute.
An iced caramel macchiato with almond milk might take 5.

So even if you're earlier in the queue, someone after you might get their order first.

📌 Design Insight: Queues buffer load, but they don’t guarantee equal wait times. Task complexity affects throughput.

3. Baristas = Event Consumers

Baristas don’t wait for orders to be assigned.

They listen for new orders, then pull one off the queue when ready.
This is event-driven architecture: workers subscribe to a stream of tasks and pick them up independently.

More baristas = higher parallelism = better throughput.

No need to coordinate who does what. Each instance is stateless and autonomous.

📌 Design Insight: Event-driven systems are more scalable and loosely coupled.
You can scale consumers horizontally with minimal coordination.

4. Espresso Machines = Shared Resource Bottleneck

Each barista can’t make every drink right away.

Espresso drinks rely on shared machines—typically just one or two in the shop.

That introduces resource contention.
Even if you have 5 baristas, only 2 drinks can be brewed simultaneously.

This is like:

• Database connection limits

• CPU-bound microservices

• Shared memory or I/O locks

📌 Design Insight: Systems must manage contention and concurrency carefully.
Shared resources need pooling, backpressure, or load shedding.

5. Order Ready = Push Notification

Customers don’t walk up every 30 seconds asking, “Is my drink ready?”

Instead, the barista calls your name (or order number) when it’s done.

This is push-based notification, far better than polling.

Polling wastes bandwidth and computing resources. Push updates are efficient and timely.

📌 Design Insight: Use push notifications (WebSockets, SSE, Pub/Sub) over polling where possible, especially for status updates or async task completions.

Real-World Considerations

Distributed systems aren't perfect. Coffee shops aren't either.

Here’s what can go wrong:

• Load spikes: Morning rush = write spike. Queue fills up, latency increases.

• Skewed processing: One complex order delays others. Impacts fairness.

• Dropped task: Barista forgets an order. You need retry or reconciliation logic.

• Backpressure: When the queue is too long, the system should throttle intake.

All of these require planning, just like in software systems.

Final Thought

Distributed systems don’t start in the cloud.
They start with understanding how work flows, where it gets stuck, and who needs to be notified.

You don’t need Kubernetes to learn system design. You just need to watch how a coffee shop works under pressure.

Next time you're in line, look around and ask:

• Where’s the queue?

• What’s async?

• What’s the bottleneck?

• What breaks under load?

If you can model a coffee shop, you can model a backend system.

System design isn’t theory; it’s observation. And the world is full of working systems.

It’s all there, hiding in plain sight.

---

System Design Classroom is a reader-supported publication. To receive new posts and support my work, consider becoming a paid subscriber.