Distributed Systems: Why Independence Beats Coordination

7 min read

Came here from Instagram, LinkedIn, X or YouTube? Here is the full source list you came for. Everything below is built from these, nothing else.

The article

• Why Distributed Systems Prefer Independence over Coordination, ByteByteGo, October 22, 2026

Every time one part of your system has to wait for another part, you have made both of them weaker. My take is simple: in a distributed system, independence should be the default, and coordination should be something you pay for on purpose, in the few places where you have no other choice.

Most teams drift the other way. They split a product into services, replicas and workers, and then wire those pieces together so tightly that nothing can move unless everything else answers. You end up with the cost of a distributed system and very little of the freedom.

ByteByteGo published a piece on exactly this on October 22, 2026, and its framing is the cleanest I have seen. Most of that article sits behind a paywall, so I am working only from the part that is public: the definition, the examples and the outline. That turns out to be enough to make the case.

Key takeaways

• ByteByteGo defines coordination as components talking to each other and waiting on the answer to get something done.
• Its 3 everyday examples are a service waiting for approval, a database waiting for replica acknowledgment, and a worker waiting for a lock.
• The more pieces you divide a system into, the more often one piece needs another, so coordination grows as you split.
• Every wait ties one component's progress to another component's response. That is the cost.
• The counter-argument (some things must agree) is real, but it argues for less, deliberate coordination, not none.
• The fix starts with one habit: list every wait in a request path and justify each one.

What does coordination actually mean in a distributed system?

Start with the setup ByteByteGo uses. In a distributed system, your components run in separate processes or on separate machines. Those components can be application services, database replicas or background workers.

Because the system is divided into so many pieces, one component often needs another to finish a job. And it often has to wait for that other component's response.

That talking and waiting is coordination. The article gives three examples, and I like them because you have almost certainly built all three:

1. One service waits for another service to approve a request.
2. A database waits for acknowledgment from its replicas.
3. A worker waits for a lock.

Read those again and notice the verb they share. Every single one is a wait.

Why is coordination a challenge for distributed systems?

This is the core of my argument, and it follows directly from that definition.

When component A waits on component B, A is no longer in charge of its own speed. It moves as fast as B answers. If B is slow, A is slow. If B is down, A is stuck. You split them onto separate machines so they could live separate lives, and then a single wait glued their fates back together.

Now look at the three examples through that lens.

The approving service. The service making the request cannot finish until the approver responds. The approver's bad day becomes the caller's bad day, and the caller's users never see the approver at all. They just see your app hanging.

The database and its replicas. Replicas are there so your data has more than one home. But if a write waits for replicas to acknowledge, the write is now tied to those replicas being reachable and responsive. The copies meant to protect you are now on your critical path.

The worker and the lock. A lock is there so two workers do not do the same thing at once. But while one worker holds it, every other worker that wants it waits. Workers you added to get more done in parallel end up taking turns.

None of this means those designs are wrong. It means each wait is a cost, and the cost is always the same shape: your progress now depends on something you do not control.

You split the system so the parts could move on their own. Every wait you add quietly takes that back.

How does coordination creep into a system?

Nobody sets out to build a tightly coupled system. It arrives one reasonable decision at a time.

ByteByteGo points at the mechanism in one line: because we divide the system into so many components, it is common for one to need another. That is the trap. Splitting is the move we reach for to make systems independent. But each split also creates a new boundary, and every boundary is a place where one side might end up waiting on the other.

So the more you break things apart, the more chances you create for coordination. Inside one process, calling a function does not feel like coordination. Once that same call crosses into a separate process or machine, it is exactly the talking and waiting the article describes.

This is why I think independence has to be a stated preference, not a hope. If you do not push against it, the number of waits in your system tends to go up as the number of components does.

The strongest counter-argument: some things have to agree

Here is the best case against my take, and I want to give it properly.

Coordination exists for good reasons. That approval step might be what stops a bad request from going through. The replica acknowledgment might be what you rely on to know a write landed in more than one place. The lock might be what stops two workers from processing the same job twice. Strip those out in the name of independence and you get a fast system that is wrong.

A fast wrong answer is worse than a slow right one. That argument is correct, and anyone who tells you to remove all coordination is not describing a system you would want to run.

But look at what the argument actually proves. It proves that some waits protect correctness. It does not prove that every wait does. A wait that protects something you can name is earning its place. A wait that exists because the first version was written that way is not.

So my answer is this: the counter-argument is a reason to be precise about coordination, not a reason to be relaxed about it. Keep the waits that protect something specific. Remove or move the rest. That is still "prefer independence". It just means preference, not absolutism.

What should you do about coordination in your own system?

You do not need a rewrite. You need a list and some honesty.

1. List every wait on your main request path. Every service call that blocks, every replica acknowledgment, every lock. Write them down in one place. You probably have never seen that list, and that is the point.

2. For each wait, name what breaks without it. If you can say "without this, a job runs twice" or "without this, a bad request gets approved", keep it. If the honest answer is "nothing, we just always did it this way", it is a candidate to remove.

3. Ask whether the wait has to happen now. Some coordination is needed eventually but not before you answer the user. Those are the ones worth moving off the request path, so the user is not the one waiting.

4. Keep locks as narrow as you can. If a worker only needs exclusive access to one thing, do not let it hold access to more. The fewer workers competing for the same lock, the less they take turns.

5. Treat every new boundary as a decision about waiting. When you split out a new service, ask up front whether the old caller will now have to wait on it. If yes, decide that on purpose instead of discovering it later.

ByteByteGo's outline covers the same ground in its later sections: why coordination becomes a challenge, how it increases in a system, how to reduce it, and strategies to handle it. If you have a subscription, those are worth reading for the specific techniques. The principle underneath them is the one in the title.

FAQ

What is coordination in a distributed system?

Coordination is when separate components, such as services, database replicas or background workers, talk to each other and wait for a response to get something done. ByteByteGo's examples are a service waiting for approval, a database waiting for replica acknowledgment, and a worker waiting for a lock.

Why do distributed systems prefer independence?

Because every wait ties one component's progress to another component's response. If the other side is slow or unavailable, the waiting side is held up too. Independent components can keep working on their own, which is the reason you split a system into separate pieces in the first place.

Does preferring independence mean removing all coordination?

No. Some waits protect correctness, like stopping two workers from doing the same job or making sure a request is approved before it goes through. The point is to keep only the coordination you can justify and to remove or move the rest off the critical path.

Why does coordination increase as a system grows?

Because you divide the system into more components, and each one is more likely to need another to finish its work. Every new boundary is a new place where one side may end up waiting on the other.

Pick your busiest request path this week and write down every wait on it, then grab the free tools on Art of Code for the boring parts while you do. If you want to work on systems like these for a living, browse the open roles on Art of Code Jobs.

Written by Adithya Guttha, Founder of Art of Code.