Microservices With No Manager: Genius or Chaos?

Picture a pizza shop with three stations: dough, oven and delivery. An order comes in. How does that pizza get from one station to the next?

In the first shop, a manager stands in the middle and calls out every step. In the second shop, there's no manager. A ticket goes up on the rail, and each station jumps in as soon as the one before it finishes.

Software teams face the same choice with microservices. The names are orchestration and choreography. Here's how to tell them apart, and when each one is the right call.

The shop with no manager (choreography)

Every station knows its own job and watches for its cue. Dough is ready, so the oven starts. The pizza comes out, so delivery picks it up. Nobody holds the whole plan. It only exists as the sum of everyone's reactions.

Most days, that's lovely. Then a customer calls: "Where's my pizza?" Nobody can say. You walk from station to station asking.

In software, services publish events to a message broker and react to each other's events. To trace one order, you check the payment logs, then the broker, then the inventory consumer, then shipping. It works. It's just a long walk.

The shop with a manager (orchestration)

The manager holds the plan. Start the dough, then the oven, then call the driver. If the oven jams, the manager knows which pizza is stuck and where to send it. When a customer calls, the manager checks the board and answers in ten seconds.

In software, an orchestrator calls payment, then inventory, then shipping, in order. It retries failed steps and knows exactly where each order stands.

Side by side

So which shop should you run?

A shop that only makes toast doesn't need a manager. If a service just reacts to events, like storing readings sent by an IoT device, choreography is plenty. There's no sequence to protect.

Once several steps have to happen correctly and in order, a manager earns their pay. Think payment, stock, a fraud check and a shipping label, with retries when something fails.

The two are also closer than they sound. Choreography leans on a message broker to hold messages until services pick them up. An orchestrator works like a smarter broker, one that calls each service at the right time. What you get on top is visibility into everything going on.

"But what if the manager calls in sick?"

It's the usual objection, and it cuts both ways. In choreography, the rail itself, the broker, is the single point of failure. Either way, the answer is the same: pick a reliable one and run it with replicas.

If you want a manager for your services and APIs, Unmeshed can be that layer.