Cheat sheetMS-05

Monolith to Microservices

Microservices & APIs / Monolith to Microservices

Migrate incrementally, not big-bang. The strangler fig reroutes functionality around a running monolith; database decomposition is the central, hardest challenge.

01
Strangler figProxy in front of the monolith intercepts calls; reroute functionality to new services path by path, reversibly.
02
Decomposition seamsExtract cohesive, low-risk, high-value bounded contexts first; avoid the most entangled subsystem initially.
03
Database decompositionUntangle shared tables via views, wrapping services, or change-data-capture; the true crux of migration.
04
Safe cutover patternsBranch by abstraction and parallel run let you build and validate before switching traffic.
⚑

Never plan a big-bang rewrite. Put a gateway in front of the monolith and move one clean seam at a time, keeping each route reversible. Treat data decomposition as the main effort: give the new service its own store and sync it (CDC) during transition, validating with a parallel run before final cutover.

Extract NotificationsGateway routes notification traffic to a new service; CDC keeps its store in sync until the shared tables are retired.
Validate firstRun old and new notification paths in parallel, compare outputs, then flip the gateway to the new service.
Strangler fig lives at the API gateway/proxy
Split data: view -> wrapping service -> own store + CDC
Branch by abstraction, then parallel run, then cut over
strangler-figdecompositiondatabase-splitmigrationcdcincremental
review in 6d