Three years ago, we went all-in on microservices for a client’s platform. Forty-two services, each with its own repo, CI pipeline, and deployment cadence. On paper it looked like textbook distributed systems. In practice, it was a coordination nightmare.
The breaking point came when a routine feature — adding a new field to a user profile — required changes across seven services, four API contracts, and three database schemas. What should have been a two-day task took two weeks. We spent more time managing service boundaries than building product.
The migration back to a modular monolith took about four months. We didn’t just collapse everything into one codebase — we designed clear module boundaries with enforced dependency rules. Each module owns its database schema, exposes a typed API to other modules, and can be extracted back into a service if it ever needs to scale independently.
The results were dramatic. Deployment frequency went from once a week (coordinated across services) to multiple times per day. Developer onboarding time dropped from three weeks to three days. And our infrastructure bill fell 40% because we no longer needed a Kubernetes cluster to run what is fundamentally a CRUD application.
The lesson isn’t that microservices are bad. It’s that they’re a scaling solution, not a starting architecture. If your team is under 20 engineers and your traffic doesn’t require independent scaling of components, a well-structured monolith will get you further, faster, with less overhead.