The Morning Rush is a Distributed System (And Other Things I Think About While Steaming Milk)

There is a moment that happens maybe twenty minutes into a busy morning rush at a good coffee shop. It doesn't announce itself. One second you're scrambling — tickets are piling up, someone needs change, the espresso machine needs a portafilter swap and nobody's free to do it. And then something shifts. The chaos doesn't go away but it becomes organized chaos. Everyone knows where to be. Nobody's talking. Nobody's assigning tasks. Things are just... happening. Drinks are moving. The line is shrinking.

I've been a barista long enough to recognize this moment when it arrives. I've also been a CS student long enough to recognize what it actually is.

It's a distributed system coming online.

Let me back up

I used to work at a bigger chain. High volume, high speed, mobile orders dominating the queue before the first customer even walked through the door. Everything optimized for throughput. It was efficient in a clinical sort of way.

Now I work at a local cafe. We make our syrups in house. The space is homey. Regulars know our names. The vibe is completely different — but the morning rush is still a morning rush, and the problem it poses is the same problem it poses everywhere: How do you coordinate multiple people, multiple tasks, multiple queues of work, under time pressure, without stopping to have a meeting about it?

You don't have time to stop and assign roles. You don't have time to say "you take register, you pull shots, you steam milk, you run food." The line doesn't wait for your org chart.

So you don't make one.

How it actually works

There's no formal system. Nobody wrote it down. But every experienced barista knows it implicitly, the same way experienced engineers know certain patterns without having to look them up.

Someone is on the bar making drinks. In our shop that person is effectively the primary node — the one whose output rate determines everything else. Drinks don't leave without them. So when they need something, that need gets heard first. If they call for more oat milk, someone gets oat milk. If the espresso shots aren't pulled, someone pulls them. The bar barista doesn't have to manage the team — they just have to communicate what they need, and the team routes around it.

Everyone else is filling gaps. Someone steps away from register to grab cups from the back. In the half second they're gone, whoever is closest drifts toward the register naturally, without being asked, because there are customers and the register needs to be staffed. The person returns, sees the register covered, moves to wherever the next gap is. So on and so on.

An important distinction is that it's not choreography. It's more like... each person is running a simple loop. Look around. Find the highest priority uncovered need. Cover it. Repeat.¹

If you've taken a distributed systems course, this might sound familiar.

What this actually is

In computer science, a distributed system is a network of independent nodes that coordinate to accomplish a shared goal without any single point of control.² The interesting thing about distributed systems is that they're hard to design well precisely because there's no central coordinator telling everyone what to do. Each node has to make local decisions based on local information and still produce globally correct behavior.

A well-run coffee bar during a rush is solving exactly this problem. Each barista is a node. The shared goal is drinks moving out and customers moving through. There's no central coordinator — or rather, the bar barista plays a soft coordinator role not by issuing commands but by broadcasting state ("I need shots," "I'm out of cups") that other nodes can act on.

The way tasks get assigned isn't top-down. It's emergent. Each person observes the system state and responds to it. The result, when everyone is experienced and locked in, looks almost magical from the outside — this smooth, flowing, self-organizing machine that appears to run itself.

Distributed systems researchers would call this eventual consistency with local decision-making.³ I call it a really good Saturday morning shift.

The flow state thing

There's another computer science concept hiding in the morning rush and it's less academic but maybe more universally recognizable. When you're locked in — really locked in, moving fast, not thinking about individual actions just executing them — you're in a flow state.⁴ Psychologists define it as a mental state of complete absorption where the challenge of a task matches your skill level precisely enough that you're fully engaged but not overwhelmed.

Baristas know this feeling. So do programmers. It's the same feeling.

In both cases it requires a certain kind of repetition; not mindless repetition, but skilled repetition. Your hands know what to do. Your brain is freed up to monitor the system, anticipate the next need, catch problems before they become crises. You're not thinking about how to steam milk while steaming milk. You're thinking about which drink needs to go out next and whether the shots for the one after that are ready.

The best coding sessions feel identical to me. My fingers know the syntax. I'm not thinking about how to write a for loop. I'm thinking about the architecture, the edge cases, the thing three steps ahead. The mechanical stuff happens below conscious thought. Getting into that state intentionally (in either context) is one of the more underrated skills you can develop. And recognizing that it's the same state in both contexts made me appreciate both more.

What happens when the system breaks

Every distributed system has failure modes. Ours is a new hire who doesn't know the protocol yet.

Not their fault. Everyone is new once. But the implicit coordination that experienced baristas do automatically — the gap-filling, the priority sensing, the knowing-without-being-told — has to be learned. It can't be explained in an onboarding document. It has to be lived.

Until it's internalized, the system loses its magic a little. You notice the shots aren't pulled. You notice the register unstaffed for a beat too long. The constantly chugging streamlined machine gets a little choppy. The experienced people pick up the slack, which means they're covering their own work and watching for gaps the new person missed.

This is exactly what happens in distributed systems when a new node joins a network that relies on implicit protocol knowledge. The system degrades slightly until the node is calibrated. Then it recovers.⁵

The solution in both cases is the same: time, repetition, and patient experienced nodes who keep the system running while the new one learns.

The thing I didn't expect to learn

I didn't take the barista job to learn about computer science. I took it because rent is real and tips are nice and I genuinely like coffee.

But there's something that happens when you spend enough time in a domain that requires coordination, timing, and performance under pressure — you start to see the abstractions. The patterns. The ways that the problem you're solving in one context is the same problem showing up in a completely different one.

A morning coffee rush and a distributed database are not the same thing. But they are both solving the problem of coordinating parallel work without a central authority, under time pressure, with imperfect information. And the intuitions you build in one transfer to the other in ways that are hard to predict but very real.

I make better software for having made a lot of lattes. I'm almost certain of it.

Footnotes