Untangling a 'microservices' platform that was really a distributed monolith

Friday afternoon. Engineering had blocked off four hours for a 'routine' deploy. By 9 PM, three services were rolled back, the on-call rotation had been activated twice, and the VP of Engineering was eating cold pizza in a conference room asking the question no one wanted to ask out loud: 'How did shipping a feature get this hard?'

Two years earlier, the team had proudly migrated to microservices. They had the t-shirts. They had the conference talk. What they didn't have was independence — every service still talked to the same Postgres database, every schema change required a coordinated deploy across four teams, and every outage cascaded through the whole platform like a row of dominoes.

We sat with each lead engineer and asked one question: 'If you could put a wall around your service, where would the wall actually go?' The answers didn't match the existing service boundaries. They matched the business domains the team had been fighting against for two years. That's where the redesign began — not with technology, but with admitting where the real seams were.

• Mapped real service boundaries against current data ownership and deploy coupling
• Designed a target architecture with 4 bounded contexts and event-driven sync
• Authored ADRs explaining trade-offs the team could defend to the board
• Built a phased migration plan with rollback paths at every checkpoint — no big-bang cutovers

The team shipped the first migration phase in 8 weeks, cut deploy time from 4 hours to 18 minutes, and stopped the cascading-failure pattern entirely. Friday afternoons stopped being scary. The on-call engineer started sleeping through the night.