Alok Ranjan Daftuar

Posted on Aug 25 Originally published at aloknecessary.in

Microservices by Default: The Organizational Constraints Nobody Puts in the Architecture Diagram

#devops #microservices #architecture #distributedsystems

"We're moving to microservices" has been the architectural ambition of engineering teams for a decade. More than 40% of organisations now report regretting at least some of those decisions. One team's consolidation back to a monolith: response times improved 13x, AWS costs dropped from $18K to $2.4K/month, deployment time fell from 45 minutes to 6 minutes.

These are not teams that failed at microservices. They implemented them correctly — and discovered the operational premium was not proportional to the benefit.

The Distributed System Tax

Every network boundary introduces failure modes that don't exist in-process: retries, circuit breakers, idempotency, distributed tracing, timeout budgets, schema versioning. This tax consumes 30–50% of engineering capacity once you cross the process boundary.

What you pay per service boundary:

Network:      Retries, circuit breakers, timeouts, idempotency keys
Observability: Distributed tracing, per-service dashboards, N on-call rotations
Deployment:   N pipelines, N rollback procedures, compatibility windows
Data:         No foreign keys, eventual consistency, data duplication, sagas

Multiply by number of services. Then ask: does the benefit justify this?

Conway's Law Is a Constraint, Not a Suggestion

Microservices deliver their promise only when the team structure supports end-to-end ownership without cross-team coordination for routine changes.

Developer:  "We're splitting into order-service, inventory-service,
             and payment-service."
Architect:  "Which team owns each?"
Developer:  "The same team. Us."
Architect:  "So you're paying the distributed system tax for three
             services, with no autonomy dividend, because one team
             owns all three."
Developer:  "..."
Architect:  "How many engineers do you have?"
Developer:  "Seven."

The Inverse Conway Maneuver: restructure teams first. The architecture follows. Decomposing architecture first and hoping teams catch up is how seven engineers end up debugging a distributed trace across five services for a bug that would have been a five-line stack trace in a monolith.

When Microservices Are Premature

Fewer than three independent teams — communication overhead of service boundaries exceeds coordination overhead of a shared codebase
Domains still evolving — wrong service boundaries require data migration and interface deprecation; wrong module boundaries are a refactoring task
Primary bottleneck isn't deployment frequency — microservices won't fix slow tests, hiring, or infrastructure cost

When Microservices ARE Worth It

Multiple autonomous teams with clear domain ownership
Genuinely divergent scaling requirements (>5x difference between components)
Compliance isolation requirements (PCI-DSS, HIPAA)
High deployment frequency at scale (dozens of deploys/day across teams)

The Modular Monolith — The Default That Gets Skipped

A single deployable with enforced module boundaries aligned to business domains. Not a monolith with good intentions — a monolith where boundaries are enforced by build tooling.

/src/modules
  /orders/api          ← public interface (what other modules may call)
  /orders/domain       ← internal (not accessible from other modules)
  /payments/api
  /payments/domain
  /inventory/api
  /inventory/domain

Rule: orders may only import from payments/api
      Enforced by ArchUnit, NDepend, or equivalent

Benefit: when you extract payments into a service,
         the boundary is already clean. The API is already defined.
         The migration is a deployment change, not a redesign.

The Decomposition Decision Framework

Step 1: What specific problem is decomposition solving?
Step 2: Do the organisational prerequisites exist?
        - Team exists to own the service end-to-end?
        - Team can deploy without coordinating with others?
        - Service interface is stable?
Step 3: Use the strangler fig — extract one bounded context at a time

Warning Signs

You have a distributed monolith:

Services deployed together in fixed order
Changes to Service A always require changes to Service B
Production incidents involve debugging 4+ services simultaneously

Your monolith doesn't need decomposing:

Deploy in under 10 minutes
Teams work in clearly separated namespaces
On-call incidents debuggable with a single log stream
Can scale horizontally without issues

Read the Full Article

This is a summary of the fourth post in the Cloud Defaults Reconsidered series. The full article includes the complete distributed system tax breakdown, Conway's Law analysis, modular monolith implementation patterns, and the full decomposition decision framework:

👉 Microservices by Default — Full Article

The full article includes:

Complete distributed system tax enumeration (network, observability, deployment, data)
Conway's Law and the Inverse Conway Maneuver in depth
Three common misconceptions debunked (scaling, deployment safety, "get boundaries right later")
Modular monolith implementation with enforcement tooling
Warning signs for distributed monolith vs well-structured monolith
Full decomposition decision framework (pain point identification, prerequisite checklist, strangler fig extraction)
Key takeaways with actionable thresholds

DEV Community