Monolith to microservices migration represents the strategic decomposition of tightly-coupled applications into independently deployable services. This architectural transformation became standard practice among high-scale companies between 2010-2015, driven by the need for team autonomy, deployment independence, and bounded scaling. The migration itself is a multi-phase journey requiring careful planning around domain boundaries, data ownership, deployment strategies, and organizational alignment—not a one-time rewrite. The strangler fig pattern emerges as the industry-proven approach because it allows incremental risk mitigation while maintaining production stability, contrasting sharply with big-bang rewrites that typically fail at scale.
What This Cheat Sheet Covers
This topic spans 20 focused tables and 113 indexed concepts, 107 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: Migration Strategy Patterns
The high-level playbooks for how you carve a service out of a monolith without a risky big-bang rewrite. Strangler Fig dominates production migrations—you reroute one slice of traffic at a time to new services while the old code keeps running—and the rest are variations on the same theme of switching implementations safely: branch by abstraction to swap behind an interface, parallel run to compare old and new before committing, database-first to untangle data ownership early.
| Pattern | Example | Description | |
|---|---|---|---|
Route /orders/* → new serviceRoute /users/* → monolith | • Incrementally replace monolith functionality by routing traffic to new services while old code remains • most widely adopted migration approach for production systems | ||
interface PaymentGatewayclass LegacyPayment implements PaymentGatewayclass NewPayment implements PaymentGateway | Create abstraction layer in monolith code that allows switching between old and new implementations via configuration without branching source code | ||
Send requests to both old & new Compare responses Route production to validated system | • Run new microservice alongside monolith with same requests • compare outputs to verify correctness before cutover | ||
Split shared DB into schemas Extract service after data separation | • Separate database ownership before extracting service logic • reduces coupling but requires careful transaction boundary analysis | ||
Micro-frontends: /header → Header Service/cart → Cart Service | • Decompose UI into independently deployable fragments owned by backend services • enables true end-to-end service ownership |