Five Microservices, Three Engineers: Perfection Wasn't the Problem

Var0's July 19, 2026 essay, "Perfection is not over-engineering", makes its case with a sharp example: three people maintaining five microservices that share data. The team may gain independent deployments, but it also trades database-enforced relationships for network calls, loose identifiers, and more ways for data to drift.

I buy the useful half of the argument. Caring about quality is not the same as over-engineering. I get stuck on the promise that sufficiently clear requirements will reveal one perfect solution. Architecture rarely gets that tidy. Requirements conflict, evidence arrives late, and today's constraint can become next quarter's mistake. I would rather have a defensible design whose bets are written down.

Quick answer

Question	My read
What is the source arguing?	Over-engineering means solving a problem the team does not have, while careful work against clear constraints can produce the right solution.
What is persuasive?	The cost of architecture should be tied to a real product or operating need, not fashion or hypothetical scale.
What is overstated?	Clear requirements do not always leave one possible answer. Cost, speed, reliability, team skill, and reversibility can still support several reasonable designs.
What would I do?	Write down the problem, the evidence, the rejected simpler option, and the condition that would justify more complexity.

The five-service test

The essay's microservice example works because the bill is concrete. A foreign key inside one database can enforce a relationship directly. Split the data across services and that guarantee no longer comes for free. The team now needs a plan for failures, stale references, deployment order, monitoring, and repair.

Microservices are a conditional choice. Martin Fowler's microservice prerequisites, published in 2014, names the operating capabilities that should already exist: rapid provisioning, basic monitoring, rapid deployment, and close cooperation between developers and operations. Independent deployment is valuable when organizational or scaling pressure calls for it. Without that pressure and those capabilities, the team takes on extra work before independent deployment has paid for itself.

Requirements need evidence

The source is strongest when it treats a library, API, or internal tool as a product with users. That move forces an engineer to ask who needs the system and what job it must do. Microsoft's design guidance makes a similar point from the user side: design for the probable, not the possible. Features and controls that serve unlikely scenarios still impose effort on everyone who encounters them.

But a requirement is not automatically true because someone wrote it down. "Must scale globally" may be a forecast. "Teams need independent deployments" may conceal an ownership problem. "We need flexibility" may mean nobody wants to make a decision. Those statements can justify almost any abstraction unless the team attaches evidence and a time horizon.

I would widen Var0's definition here. A team can over-engineer for a real problem by paying too much, too early, while its timing and size remain unknown. High standards are fine. Unexamined assumptions are the part I want exposed.

Measure the cost people inherit

Google's Site Reliability Workbook treats simplicity as an end-to-end property, not a code-style preference. Its simplicity chapter suggests practical proxies such as training time, explanation time, administrative diversity, and the number of deployed configurations. I like these measures because they expose costs that an architecture diagram hides.

A design can look elegant to its author and still be exhausting to operate. If a new engineer needs weeks to understand the service map, or every component has a different deployment ritual, the system is consuming team capacity. That capacity belongs in the requirements alongside throughput and latency.

Public developer discussion shows why the label alone settles nothing. In an ExperiencedDevs thread about a questionable microservice design, commenters asked which specific constraints demanded separate services and pointed to cases where isolation can help, including distinct resource needs or compliance boundaries. That is the response I find useful: show the requirement that earns the split.

Perfection needs an expiry date

I want to keep the source's ambition and change its finish line. Good engineering should be precise, avoid accidental complexity, and take internal products seriously. Calling a design perfect can still hide an awkward fact: we may have chosen well for assumptions that will not survive contact with users.

I would choose the smallest design that satisfies the evidence in front of the team, then record which constraints made it win. The team needs a path to change it and a reason to revisit the decision when usage, staffing, or failure patterns move. If five microservices still earn their keep under that test, build them properly. If they do not, the problem was the complexity bill and the evidence that never supported it.