Microservices vs Monolith

"Should we go microservices?" is one of the most consequential — and most misunderstood — architectural decisions. Pick microservices too early and you'll spend years debugging distributed systems instead of building features. Pick monolith too long and your team grinds to a halt as everyone steps on each other's deploys. The right answer depends entirely on team size, complexity, and operational maturity.

Most teams who say "we're moving to microservices" should actually build a modular monolith first. Most teams already on microservices wish they had started with one.

It's not a binary. Real architectures live on a spectrum:

• Big-ball-of-mud monolith — single deploy, no internal boundaries. The horror story. What every monolith becomes if undisciplined.
• Modular monolith — single deploy, but enforced internal module boundaries (separate packages, no cross-imports, talks via interfaces). 80% of microservices benefits, 5% of the cost.
• Service-oriented (a few services) — 3-10 services aligned to subdomains. Most companies' sweet spot.
• Microservices (many small services) — 50+ services. Only justifies itself at FAANG scale or in genuinely independent product teams.
• Nanoservices / Lambda functions — every endpoint is its own deployment. Operational nightmare. Almost always wrong.

• Independent deploy. Team A ships without coordinating with Team B. The biggest real benefit.
• Independent scaling. The recommendation service needs 10× the capacity of the user service. Scale just it.
• Tech heterogeneity. Use Rust for the latency-critical service, Python for the ML service. Each team picks.
• Fault isolation. One service crashing doesn't take everything down (with proper circuit breakers).
• Team autonomy. Conway's Law says your architecture mirrors your org. Microservices align technical boundaries with team boundaries.

The hidden taxes nobody talks about until they're paying them:

• Network calls everywhere. What was a function call is now an HTTP/gRPC request. 1ms becomes 10ms. Failures everywhere.
• Distributed transactions. The atomic UPDATE across two tables becomes a saga with compensating actions.
• Operational complexity. 50 services × 3 environments × 5 dependencies each = thousands of deployment artifacts. Need service mesh, distributed tracing, centralized logging.
• Schema coordination. Service A depends on Service B's API. B changes the API → A breaks. Now you need API versioning, backwards compatibility forever, contract tests.
• Local development hell. "To run my service I need to spin up 12 dependencies." Hours of setup; productivity drops.
• Cost. Each service has overhead — its own pod, its own DB connections, its own monitoring, its own on-call rotation.

The pattern most successful product teams converge on:

1. Single deployable artifact (one Docker image, one fleet, one DB connection pool).
2. Internally organized into modules that mirror your bounded contexts — orders, users, payments, inventory.
3. Modules can only call each other through explicit interfaces — never direct DB joins, never importing internal classes.
4. Each module owns its tables; cross-module queries go through the owning module's interface.
5. Linter/CI enforces the boundaries: "orders module cannot import payments.internal.*"

You get 80% of the architectural benefits (clear boundaries, replaceable modules, isolated changes) without the operational cost. When a module genuinely needs independent scaling or its own deploy cadence, you can extract it to a service — and the work is straightforward because the boundaries are already clean.

Shopify's monolith — millions of lines of Ruby — runs this way. So does Stripe's main API. Both could afford full microservices; both deliberately avoided it.

E-commerce architectures choose modular monolith vs services per domain. News feed at scale uses microservices for ranker / feed-store / fan-out independently. Uber's microservice fleet is the textbook example of the pattern at scale.