Every architecture diagram I have ever been shown in a diligence review is beautiful. Clean boxes, confident arrows, the word “scalable” hovering over it like a blessing. Then I ask what it costs to run — not in cloud bills, in people — and the room goes quiet.
Microservices are not wrong. They are expensive in ways the diagram never shows. After years of auditing builds, I have learned to read past the boxes and price the parts nobody drew. Here is where the tax actually lands.
1. The orchestration overhead nobody budgeted
A monolith has one deploy pipeline, one runtime to monitor, one log stream to search. Split it into twelve services and you now have twelve pipelines, twelve dashboards, twelve sets of alerts — plus the service mesh, the API gateway, and the contract testing to keep them honest with each other. Each of these is small. Together they are a full-time job, sometimes two, that produces zero customer-facing value. In diligence, I count the services and then I count the platform engineers. If the second number is smaller than the first deserves, the team is paying the tax in weekend pages instead of headcount.
2. The deployment choreography
In a monolith, a deploy is an event. In a distributed system, a deploy is a negotiation: which services can go out together, which need backward-compatible contracts first, what happens when service A ships before service B is ready. I have audited teams where a “simple” release required a spreadsheet, a war room, and a rollback plan with seventeen steps. The architecture promised independent deployability. The reality was a distributed monolith — all of the coupling, none of the simplicity. The audit question: show me your last three deploys. If any of them needed a human choreographer, the independence is theoretical.
3. The cognitive load on every new hire
This is the tax founders feel last and hardest. A new engineer joining a monolith reads one codebase and starts contributing. A new engineer joining a fifteen-service system must learn fifteen codebases, the contracts between them, the deployment topology, and the tribal knowledge of which service secretly depends on which. Onboarding stretches from days to months. Every architectural decision the original team made for good reasons becomes archaeology for the next team. When I diligence a startup, I ask how long it takes a new hire to ship their first production change. The answer tells me more about the architecture’s true cost than any diagram.
4. Data consistency, the quiet killer
The diagram shows services. It does not show the distributed transactions, the saga compensations, the eventual-consistency windows where the data disagrees with itself. Getting this right is genuinely hard engineering, and most teams I audit have not done it — they have hoped it would not matter. Then it matters: double-charged customers, inventory that oversells, reports that contradict the dashboard. Fixing consistency after the fact means re-architecting the seams, which is the most expensive kind of rework because it touches everything.
5. The team the architecture demands
Here is the part nobody puts in the pitch deck: microservices done well require a level of operational maturity — platform engineering, SRE practice, contract discipline — that most startups do not have and cannot hire for yet. The architecture assumed a team that does not exist. So the tax gets paid in the worst currency: senior engineers spending their time on plumbing instead of product, outages nobody fully understands, and a velocity curve that bends the wrong way as the system grows.
When the tax is worth paying
None of this means microservices are a mistake. They earn their keep when teams are large enough to need independent ownership, when domains genuinely change at different speeds, when the blast radius of a deploy must be contained. The tell is whether the organization shaped the architecture or the architecture is shaping — and straining — the organization. Conway’s law cuts both ways.
Reading the diagram in diligence
If you are evaluating a company, do not admire the boxes. Price them. Count services against platform headcount. Ask for deploy history, onboarding time, and the last consistency incident. Ask what the system would look like if they had built the boring version — and whether they can articulate why they didn’t. The teams worth backing can answer all of this without flinching. The ones paying the tax usually can’t, because they have never added it up.
The architecture diagram shows what the system is. The tax shows what it costs to keep it alive. A good diligence review prices both.
GhostOp is a technical product studio. We turn difficult ideas, fragile builds, and hidden system problems into products that work: fast, unsentimental assessments of what a system really costs to run. See how the studio works.