Recap — When to Split, When Not To

# When to Split, When Not To The microservices-vs-monolith debate is over-hyped. Most teams should start with a monolith; some should split. Knowing when is the skill. ## What's a monolith Single codebase, single deployment unit. ``` [ One Application ] ├── User module ├── Order module ├── Payment module └── Notification module All compiled together, deployed together. ``` Pros: - Simple development (one repo, one build). - Simple deployment (one artifact). - Easy refactoring (cross-module changes in one commit). - Easy to debug (single process). - Performance (function calls, no network). - Transactions across modules (one DB). Cons: - All teams deploy together (coordination). - One bug crashes everything. - Tech stack locked in (can't easily mix languages). - Scaling is all-or-nothing. ## What are microservices Many small services, each independently deployable, each with its own data. ``` [User Service] [Order Service] [Payment Service] [Notification Service] own DB own DB own DB own DB REST/gRPC REST/gRPC REST/gRPC ... ``` Pros: - Teams deploy independently. - Tech diversity (Python for ML, Go for performance). - Fault isolation (one service down ≠ everything down). - Scale specific services that need it. - Clear ownership boundaries. Cons: - Operational complexity (many deployments, service discovery, monitoring). - Network latency between services. - Distributed transactions (sagas, eventual consistency). - Schema changes coordinate across services. - Debugging is hard (which service is slow?). - More infrastructure (each service needs ops). ## When microservices help Real signals: - **Team scale**: 50+ engineers across multiple teams stepping on each other in monolith. - **Deploy frequency**: teams need to deploy 10+ times/day; monolith deployments are slow/risky. - **Independent scaling**: ML service needs 100x CPU; auth service doesn't. - **Polyglot**: legitimate need for different languages. - **Domain boundaries**: clearly separable business domains (e.g., payments, shipping, catalog). ## When microservices DON'T help Anti-signals: - **Small team**: < 20 engineers. Monolith easier. - **Early stage**: requirements unclear; over-splitting = pain when you need to refactor. - **Shared data**: tightly coupled domains; splitting forces awkward cross-service queries. - **Hiring transactional bookkeeping** for a 5-person team. - **Following trend**: "Netflix does microservices" — Netflix has 1000+ engineers. ## Modular monolith — the middle ground Single deployment, but modules have strict boundaries: - Each module owns its data (no direct DB access from outside). - Modules talk via internal APIs (function calls or events). - Could extract to a service later without rewrite. ``` [ Monolith ] ├── User module (owns user_db) ├── Order module (owns order_db; calls user_module via interface) └── Payment module (owns payment_db) ``` Pros: monolith simplicity + microservice-style boundaries. Best of both for many teams. Most teams in 2026 should start here. Extract to microservices ONLY for the modules that actually need it. ## The migration path ``` Monolith → Modular Monolith → Selective Extraction → Microservices (some) ``` Steps: 1. Inside the monolith, establish module boundaries (separate packages/modules/schemas). 2. Enforce: no cross-module DB access; communicate via interfaces. 3. When a module needs independent deploy/scale, extract it as a service. 4. Iterate. Don't go monolith → microservices in one rewrite. That's the Big Rewrite anti-pattern. ## Decomposing by domain Domain-Driven Design (DDD) lens: find bounded contexts. Example for e-commerce: - Catalog (products, search, recommendations). - Order (cart, checkout). - Payment (transactions, refunds). - Shipping (logistics, tracking). - User (auth, profile, preferences). Each bounded context = candidate for its own service. They communicate via well-defined contracts (events or APIs). ## Communication patterns ### Sync (REST, gRPC) Service A calls Service B; waits. Use for: getting data needed in the request. ### Async (events, queues) Service A emits event; Service B reacts. Use for: side effects, propagation, multi-consumer. ### Mixed Most production systems mix: - Sync for "I need user data to render this page." - Async for "user updated email; sync to CRM, analytics, etc." ## Operational cost of microservices Each service needs: - CI/CD pipeline. - Monitoring + alerting. - Logging aggregation. - Service discovery / DNS. - Auth / mTLS. - Database (own or shared). - Schema versioning. - API documentation. - On-call rotation. Multiplied by N services. Significant ops investment. Mature teams: Kubernetes + service mesh + observability platform + GitOps. Small teams: just running the basics is full-time. ## Common microservices mistakes 1. **Too small.** Nano-services (one function each) = mostly RPC overhead. 2. **Shared database.** Defeat