Monolith vs microservices — the honest tradeoff

What the terms actually mean

• Monolith — One deployable application. All the business logic ships together, talks to one (or a small number of) databases, and is developed in one codebase. Doesn't mean 'one giant messy file' — a well-organized monolith has modules, boundaries, and internal APIs.
• Microservices — The application is split into many small services, each independently deployed, each with its own database (typically). Services communicate over network calls (HTTP/gRPC/message bus). Popularized by Netflix and Amazon; over-adopted everywhere else.
• Modular monolith — The compromise most senior engineers now recommend. One deployable, but internally structured as clear modules with strict boundaries. If you later need to split a module into a service, the code is already ready for it.
• Service-oriented architecture (SOA) — The 'macroservices' version. A few large services (5–15), not dozens. Often the right destination for teams that outgrow a monolith but shouldn't go to full microservices.

Why microservices got over-adopted

From about 2014 to 2020, microservices were sold as the enterprise-scale answer to slow monoliths. The pitch: independent deployment, team autonomy, technology diversity, horizontal scaling. All real benefits — for organizations that actually had the constraints those benefits solve. For everyone else, microservices imported enterprise problems (distributed transactions, cross-service debugging, network reliability, coordinated deployments) without the enterprise benefits. Most 20-engineer teams that adopted microservices spent 30–50% of their engineering capacity managing infrastructure that a monolith would have handled for free.

When to actually reach for services

• Team scale — You have 40+ engineers and they're stepping on each other's deployments. Cutting the codebase along team boundaries (one team owns one service) removes coordination cost. Under 20 engineers, this doesn't apply — you can share a monolith easily.
• Genuine scaling asymmetry — One part of the app needs 100x the resources of the rest — e.g. a real-time inference layer, a heavy background job queue, a file processing pipeline. Extract that part to a service so it scales independently. Don't extract everything.
• Compliance or security isolation — Some data (PHI, PCI card data, defense-sensitive) legitimately needs to live in an isolated system with different access controls. Splitting it out is architecture-driven, not fashion-driven.
• Technology mismatch — One part of the system genuinely needs a different runtime — a Rust service for latency, a Python service for ML. That's a valid reason to split. 'We want to try Kotlin for this new feature' is not.

What a well-built modular monolith looks like

The compromise that's winning in 2026. One deployable, one database (or a small set), but the code is organized into modules with strict internal boundaries. Modules communicate through explicit interfaces, not by reaching into each other's tables. When (if) you need to split a module into a service later, the interface is already the network boundary — the refactor is mechanical, not architectural.

• Clear module boundaries — Payments, billing, users, notifications each live in their own folder with a defined public API. No module imports another module's internal files.
• Shared database, module-scoped schemas — Postgres with a schema per module. Each module can only write to its own schema; cross-module reads go through the module's API, not raw SQL.
• One CI/CD pipeline, feature flags for rollout — Deploy the whole app together, use feature flags to gate risky changes. This is faster and safer than the microservices dance for teams under 50 engineers.
• One observability surface — One log stream, one tracing system, one alert configuration. Debugging is dramatically simpler than in a distributed system.

The cost of the wrong choice

Choosing microservices too early is the most expensive architectural mistake we regularly clean up. Typical cost of unwinding a premature microservices decomposition for a 15-engineer team: 3–6 months of dedicated work, $250K–$600K of engineering time, and a lot of caution about ever changing architecture again. Choosing a monolith too long (past 40 engineers) has costs too, but the costs are gradual — coordination friction, slower releases — and the pivot to services is more targeted (extract one service at a time). Late-monolith regret is a bad quarter. Early-microservices regret is a bad year.