Microservices are a coupling tax, not an architecture
- YT :: https://www.youtube.com/watch?v=6e9B7q3gvYY
- Original title :: The Microservices Scam Nobody Talks About
Splitting a monolith into services you didn't need to split doesn't buy autonomy - it buys a "distributed monolith," physically separated but still logically coupled, with all the coordination cost of the original plus a network tax on top. The argument: default to a modular monolith, and only extract a service when you can name a specific scaling or organizational reason to.
The distributed monolith
Splitting code into many services while business logic stays coupled means one rule change touches five services, five releases, five integration-test runs - coordination cost without the benefit of autonomy. A described case: three weeks spent tracing a customer-order bug through eight services before finding a single bad serialization in one of them. Run a coupling audit before splitting anything, or the mess just moves around.
Network calls are not free
An in-process call runs in nanoseconds; an HTTPS/TLS call runs 1-10ms. Chain five services and you've spent 50-100ms of pure overhead before any business logic runs. One team's move from microservices back to a monolith dropped average API response time from 1.2s to 89ms with zero feature changes - just removing network hops.
The cost line nobody puts a number on
Microservices carry roughly 25% higher compute overhead from orchestration, sidecars, and service mesh (Istio-style sidecars can eat up to 90% of a pod's CPU/memory); observability/tracing/logging across dozens of services runs $50k-$500k/year. Amazon Prime Video's serverless microservice stack hit a load ceiling and, after consolidating onto a monolith on EC2/ECS, cut costs over 90%. Segment hit 50+ services and rolled back after deployment friction and diverging shared libraries made the maintenance burden unaffordable. One team cited here dropped from $80k/month to $4k/month on the same feature set after moving to a monolith.
Staffing math
Mature microservices need roughly one SRE per 10-15 services, less mature setups one per 5-10; a well-architected monolith needs one or two DevOps engineers for the whole application regardless of internal module count. Running 40 services on two DevOps engineers is already underwater.
What actually predicts DORA performance
2024 DORA data: elite teams deploy ~973x more often than low performers, with 5x lower change-failure rate and far faster recovery. The variable is not "microservices vs monolith" but coupling - elite teams running modular monoliths hit the same DORA numbers as elite microservices teams.
The modular monolith
One deployable unit, clean internal boundaries, domain-owned modules, shared database with logical schema separation - like a circuit-breaker panel where each circuit is isolated without needing a separate building per appliance. Enforce boundaries with tools like ArchUnit or Spring Modulith; extract a module later only for a named reason (traffic spike, team size, polyglot requirement), and use the Strangler Fig pattern to migrate incrementally rather than freezing for a rewrite.
AI coding makes coupling worse, not better
2025 DORA research: AI tools increased task completion 21% and pull request volume 98%, but delivery performance stayed flat, because AI-generated code produces more bugs faster in tightly coupled systems, and a change can't be isolated and verified quickly when every module touches every other module. Fix coupling before adopting AI coding tools, or you accelerate into a wall.
Conway's Law as a design tool
Architecture mirrors communication structure: if three teams must coordinate to ship a feature, you already have three logically coupled services no matter how the code is drawn. The fix is restructuring team ownership (stream-aligned teams owning one business capability end-to-end, two-pizza-team sized) before touching deployment boundaries - reorganizing code without changing org structure just snaps back to the old shape within months.
When microservices are actually the right call
At 1,000+ engineers, a shared monolith creates coordination costs that scale as roughly the square of team count, not linearly; microservices bound the blast radius of a team's independent decisions (runtime upgrade, different data store) without company-wide sign-off - that organizational independence, not raw compute efficiency, is what Amazon and Netflix are actually buying. Real scaling variance (one component needing 100x the compute of another) is the other legitimate case for splitting out a service.
Architecture as a financial decision
2025 CNCF survey: 42% of organizations are actively consolidating microservices back into larger units, and service mesh adoption dropped from 18% (2023) to 8% (2025). The recommended discipline: write an architectural decision record (ADR) with a dollar figure for any architecture decision above a cost threshold, treat FinOps/cost literacy as a baseline engineering skill, and judge every distributed call, extra service, and cross-team coordination requirement as a complexity investment that has to pay for itself in business outcomes. The target metric isn't service count - it's how rarely the architecture gets in the team's way.