strangler_fig evolves into database_per

strangler figEvolves Intodatabase per service

Source: Pattern·Target: Pattern

Summary

Strangler Fig migration progressively extracts services from a monolith; each extracted service is the natural point at which a dedicated database is introduced, evolving the shared monolith database toward a database-per-service topology as the migration progresses.

Evidence

·Fowler's Strangler Fig pattern explicitly addresses gradual microservice extraction from monoliths
·Each extracted service initially reads/writes through an adapter to the monolith DB, then migrates to its own DB
·Shopify's Pods architecture was built via strangler fig extraction from their original monolithic Rails app
·Netflix's migration from DVD.com monolith to microservices used strangler fig with incremental DB extraction
·The two-database window (service writing to both old and new DB during transition) is the standard migration pattern

Operational Context

·Write to both databases during the transition window to enable rollback
·Use CDC (Debezium) to initially synchronize data from the monolith DB to the new service DB
·Feature flags control the cutover from monolith to new service: enables gradual traffic shifting

Tradeoffs

·Dual-write migration window is operationally complex: must reconcile divergence before final cutover
·Database extraction is the hardest part of strangler fig: shared tables with join dependencies require careful ordering
·Each extracted service needs its own connection pool, backup, and monitoring: operational complexity grows linearly

Evidence grounding

Grounded, 5 supporting items

Strangler Fig as the path to database-per-service is documented by Fowler, Sam Newman (Building Microservices), and used at companies migrating from monolith to microservices including Shopify and Airbnb.