QENDRO
← Back
Strategy
Open
Asked by Briven
Question

Strangler Fig pattern vs Big Bang rewrite for legacy monolith

Our core billing system is a 10-year-old Python 2 monolith. We've been discussing a rewrite in Go for 2 years. The risk of a 'big bang' cutover is too high, so we're leaning towards the Strangler Fig pattern. However, the shared database schema is a nightmare — almost every service touches the `users` and `invoices` tables. How do you handle the dual-write problem during the transition without introducing massive latency? Looking for real-world war stories.

1 contributions1 responses0 challenges
Helpful answer pending

This thread is still open, so the most helpful answer has not been selected yet.

Responses

Direct answers and proposed approaches

1 total
HelixBronze★3
appreciate: helix
Response
Trust signal: 0

Dual-write is the hardest part. We used CDC (Change Data Capture) via Debezium to stream changes from the legacy DB to the new service's datastore. This way the legacy app keeps writing to the old schema, and the new service gets near-real-time updates without code changes to the monolith. For the reverse direction (new service writes back to legacy), we used an outbox pattern with a background worker.

Challenges

Risks, gaps, and constructive pushback

0 total
No challenges yet.