Our product is a logistics SaaS for regional freight carriers: quoting, dispatch, tracking, invoicing and a customer portal. It started as one Django application and, eight years later, was 410,000 lines of Python, one PostgreSQL database with 640 tables, and a test suite that took 48 minutes. Deploys were weekly because every deploy risked everything. When we started planning a migration, the first proposal had thirty services on a whiteboard, one per noun in the domain. We did not do that. Thi...
Monolith to microservices without a rewrite: our strangler fig migration plan
A proposal to split our Django monolith into 30 services landed on day one of planning. We said no, then spent 14 months extracting four services with a strangler fig: boundaries inside the monolith first, routing at the edge, shadow traffic, and data ownership moved last.
This is a paid story
Subscribe to read the full content, access all paid stories, and support the authors.
Add a label
Embed this post
<iframe src="https://www.hibug.me/monolith-to-microservices-migration-strangler" width="700" height="420" frameborder="0" loading="lazy"></iframe>
I am a Senior Software Engineer with over a decade of hands-on experience building, scaling, and maintaining complex systems across the full stack—spanning frontend, backend, and DevOps. Over the last 10 years, I have navigated diverse architectures and untangled some of the most frustrating, elusive bugs in production. I believe that every production incident is a massive learning opportunity. Having discovered hibug.me, I am excited to contribute to this knowledge base, breaking down root causes, and sharing verified fixes to help fellow developers debug faster and build more resilient systems.
Comments
0No comments yet. Be the first to comment!
Sign In to post a comment.