From a fragile monolith to a platform that scales
A fast-growing store outgrew its single codebase. I split it along business lines, one slice at a time and without downtime, so releases became routine and traffic spikes stopped being emergencies.
The store ran on one codebase that had grown organically for years. Every release took 45 minutes to build, a single slow query could stall checkout, and each new feature made the whole system harder to change safely.
- 0145-minute builds and nervous release weekends
- 02One slow report could freeze checkout
- 03Nobody was sure what depended on what
How we got there
Measure first
Traced real user journeys and production traces to find the true bottlenecks before touching any code.
Draw the boundaries
Agreed a target architecture with the team: checkout, search and billing as independent services behind a gateway.
Migrate in slices
Moved one capability at a time behind feature flags, with the old path as an instant fallback. No downtime, ever.
Make shipping boring
Automated tests, preview environments and one-click rollbacks turned releases from events into routine.
The shape of the change
A simplified before and after. The point is not the boxes, it is that each part can now change, scale and fail on its own.
- Pages load in under a second on a typical connection
- Releases ship several times a day instead of once a week
- Traffic spikes are watched on a graph, not fought at 2 a.m.
- Teams work in parallel instead of waiting on each other
- 01Pick the order of the migration by risk, not by size.
- 02A fast rollback is worth more than a perfect plan.
- 03Observability has to ship before the first service does.
“We stopped fearing release day. The new architecture just works, and our team finally moves fast again.”