When Microservices Aren't the Answer
How we migrated to microservices, then came back to a monolith.
"Shouldn't We Be Doing Microservices Too?"
- Our team lead dropped this in a meeting. Netflix does it, Coupang does it, shouldn't we? Team of 6, B2B SaaS with 5,000 DAU.
Spoiler: 8 months later, we went back to a monolith.
We Split It Into Five
Took our monolithic Spring Boot app and broke it into User Service, Order Service, Payment Service, Notification Service, and Report Service. Each got its own DB. Inter-service communication via REST APIs.
The split took 3 months. Dividing the code wasn't hard.
The problem was data.
What Used to Be One JOIN
With Orders and Payments separated, transactions broke. An order gets created but the payment fails -- now you need to handle that. Introduced the Saga pattern, but the compensation transaction logic became more complex than the original business logic.
Reports were worse. Generating a revenue report needed data from Orders, Payments, and Users. Three separate API calls, then stitching it all together. What was a single JOIN in the monolith now took 200 lines of code.
(This is when I started feeling something was off.)
Operations Became Unmanageable
5 services times 3 environments equals 15 deployment pipelines. API version compatibility across services, tracing failure propagation, collecting distributed logs.
Too heavy for a team of 6. Adding a new feature often meant modifying 3 services simultaneously, and you had to worry about deployment order. Debugging was painful too. In the monolith, one stack trace usually pointed to the root cause. Now, with a request crossing 3 services, just figuring out where it broke became a job in itself.
Setting up Jaeger and getting comfortable with it took 2 weeks. Time that should have gone to building features.
By Month Six, the Whole Team Was Burned Out
Feature delivery speed had dropped to half of pre-migration. Tech debt piling up, customer complaints growing.
In a team retro, we were honest: "Microservices were premature for our scale." Thankfully the team lead agreed, and we started merging back into a monolith.
Merging was faster than splitting. Two months and we were back to the original structure. The day it was done, a teammate said: "I never knew I'd be this happy to see a JOIN again."
Microservices Aren't Bad Though
When the conditions are right, it's a powerful architecture. The team needs to be large enough for each service to operate independently, each service's deployment cadence needs to actually differ, and traffic patterns need to vary significantly across services.
We met none of those criteria. Six people building one product -- a monolith is the natural fit.
Eight Months of Tuition
Now we maintain a modular monolith. Separation of concerns at the code level, single deployment. When the team grows past 20 and deployment conflicts get frequent, that's when services can naturally split out.
Technology should be adopted when a problem exists, not in anticipation of one.