Software Systems Atlas

Metadata Card

Prerequisites: Chapter 11 (Layered Architecture)
Estimated Time: 40 minutes
Core Difficulty: Intermediate
Completion Milestone: Understand migration strategies from monolith to microservices and the Strangler Fig pattern

Your Progress

The first machine you designed started with 3000 parts. Two years later, it was cobbled together to 150,000 parts. Changing a label on the control handle caused the transmission module's tests to fail — because the entire machine shared the same "handle" specification definition.

The workshop master said: "Time to split." Your Task

Not every system should be broken into microservices first. The best architecture for most systems is the modular monolith — one deployment unit with clear internal module boundaries. This chapter covers when and how to split.

Required reading: Monolith pros/cons, modular monolith, Strangler Fig Selective: Database splitting strategies Advanced: Cross-database data consistency

First Layer: Modular Monolith — Don't Rush to Split

Use language features or build tools to enforce module boundaries within a single deployment unit. Java 9+ JPMS or Gradle submodules.

Second Layer: When to Split

Independent scaling needs, different deployment frequencies, team size growth, technology heterogeneity. Need at least 2-3 conditions.

Third Layer: Strangler Fig Pattern

Incrementally replace monolith functionality with new services. Phase 1: identify boundaries. Phase 2: build new service beside monolith. Phase 3: incremental migration. Phase 4: decommission monolith.

yaml

# Nginx Strangler Facade
upstream monolith { server monolith-server:8080; }
upstream player-service { server player-service:8081; }
server {
    location /api/players { proxy_pass http://player-service; }
    location / { proxy_pass http://monolith; }
}

Fourth Layer: Database Splitting

Each service gets its own database. No direct cross-service database access — all through APIs.

Fifth Layer: Anti-Pattern — Distributed Monolith

Services share the same database, synchronously call each other requiring strong consistency. All the operational complexity of microservices with all the coupling problems of a monolith.

Common Pitfalls: End-to-end tests become integration tests across services. Distributed transactions. Network calls replacing method calls without handling failures. No automated infrastructure.

Traveler's Notes

Microservices aren't the goal — isolating change velocity is. Start with a modular monolith, then use Strangler Fig to incrementally carve out services. Don't rush to split, but once split, don't look back.

Next: Microservices Patterns (Chapter 14).