From Monolith to Microservices: Lessons from a 14-Month Migration
The monolith wasn't badly written — it was just fourteen years of business logic accumulated in one codebase, to the point where a routine change touched files owned by three different teams.
We split along domain boundaries rather than technical layers: orders, inventory, and billing each became their own service with its own datastore, rather than a generic 'API layer' and 'data layer' split that would have just moved the coupling around.
The strangler fig pattern kept the migration low-risk — new traffic routed to the new services behind a proxy, while the monolith kept serving everything we hadn't migrated yet. No big-bang cutover, no multi-day outage window.
The mistake we'd avoid next time: we underestimated how much shared logic lived in database triggers and cron jobs that nobody had documented. Auditing those before writing a single line of the new services would have saved us weeks.
Fourteen months later, deploy frequency is up, and no single team can accidentally break billing while shipping an inventory feature. That isolation was the actual point — not the technology change itself.
