There's a popular myth in software that microservices exist because they scale better.
This is false.
Microservices exist because developers don't like talking to each other.
Let me clarify. Developers love talking about software. They'll talk for hours about the relative merits of functional purity versus practical impurity, or why their editor is objectively superior to yours, or why this particular bug is actually the compiler's fault.
What developers don't like is coordination.
Coordination is where you have to say things like:
"Hey, can you change your code slightly so my thing works?"
Or worse:
"Hey, can we agree on how this should work?"
That's when the trouble starts.
In the early days, we had monoliths. One big codebase. Everyone working in the same repo. If something broke, you walked over to someone's desk and said, "Hey, I think I broke your thing."
This was deeply uncomfortable.
First of all, it required walking. Second, it required admitting that your code might not be perfect. Third, it involved another human being who might ask follow-up questions.
So we invented abstraction.
Abstraction is wonderful. Abstraction says: "You don't need to know how this works, just trust me." This is the developer equivalent of leaving a note on the fridge instead of having a conversation.
An API is basically a passive-aggressive social contract.
It says:
"Here is how you may interact with my code. Do not ask me questions. Do not improvise. Do not come back unless it is literally on fire."
Once you publish an API, you've achieved something magical: you've replaced a conversation with a document. And documents don't interrupt you while you're thinking.
This was such a good idea that we immediately took it too far.
At some point, someone realised that if APIs are good, more APIs must be better.
Why have one team when you can have twelve teams, each with their own service, repository, deployment pipeline, logging stack, monitoring dashboard, and existential dread?
Microservices are often described as a technical architecture, but they're really an organisational coping mechanism.
They let us say:
"That's not my problem. That's Service B."
And Service B is owned by Team B, who sit over there, possibly in another country, possibly asleep.
This is wonderful. You no longer need to understand the whole system. You only need to understand your service, plus the twelve error states returned by everyone else's.
APIs still imply a kind of synchrony. One service calls another and waits. Waiting is dangerous. Waiting might remind you that someone else exists.
So we invented messaging layers.
With messaging, you don't talk to another service. You shout something into the void and hope that, eventually, something hears it and does the right thing.
This is the purest form of developer communication:
No eye contact No immediate response No responsibility for timing Plausible deniability if nothing happens
It's like leaving a Post-it note in a cave and calling it "event-driven architecture."
When people pitch microservices, they talk about scalability, resilience, and independent deployments.
What they don't put on the slide is:
"Allows engineers to avoid uncomfortable conversations indefinitely."
You don't need alignment meetings. You don't need to agree on priorities. You just need a schema, and even that can be versioned, deprecated, ignored, and eventually broken.
If something goes wrong, you don't argue about intent. You argue about contracts. And arguing about contracts feels technical, not personal, which is much safer.
Conway's Law says systems reflect the communication structures of the organisations that build them.
In practice, this means:
Teams that don't talk build distributed systems Teams that actively avoid talking build asynchronous, eventually consistent distributed systems Teams that really don't talk invent their own internal platforms and require a ticket to say hello
None of this is malicious. It's human. Developers are paid to think deeply, not to negotiate social nuance every five minutes.
Here's the uncomfortable truth: most microservice architectures are perfectly valid technical solutions to social problems.
Sometimes that's the right call. Sometimes it's cheaper to introduce Kafka than to fix your meeting culture.
But every once in a while, when you're debugging a system where a message failed somewhere between Service F and Service Q, and the logs are green but nothing works, it's worth asking:
"Could this have been a conversation?"
Then you close Slack, add another retry, and move on — because talking to people is still the hardest distributed system we've ever tried to scale.