Macroservice - When We Decide to 'Merge' Services Back
Sometimes over-splitting is a mistake. The story of why we decided to merge services back to reduce complexity.
This is the finale of the series, and also the most honest one. Sometimes, the pinnacle of architectural sophistication is not splitting as small as possible, but knowing when to stop.
The "Nano-services" Disease
In the middle of our journey, we fell into a trap called "Nano-services." We split everything: User service, Avatar service, Profile service, Address service...
The result was an operational disaster:
- To change a field in a user Profile, I had to fix 3 services.
- Network latency spiked because services were constantly calling each other just to get trivial information.
- Debugging a simple bug took all morning due to tracing through too many network hops.
We realized we were making ourselves miserable. We had split based on data instead of business (Bounded Context).
1. The Macroservice Concept
Macroservice is not a return to the Monolith. It refers to services of a moderate size that contain a complete, full business context.
Example: Instead of 4 small User services, we merged them into a single Identity Service. It manages everything related to user identity.
2. Why Macroservices Work for Small Teams
- Reduced Operational Overhead: Fewer services mean fewer CI/CD pipelines, fewer databases to back up, and fewer logs to monitor.
- Strong Consistency: Within a Macroservice, you can use regular database transactions (ACID). No more headaches with Saga patterns or Eventual Consistency for things that are inherently related.
- Easier Refactoring: Changing code inside a service is always 10 times easier than changing interfaces between services.
3. When to Split and When to Merge?
This is the golden rule we learned:
- Split when: Two services have different development speeds, or need to scale differently (e.g., one is CPU-intensive, one is RAM-intensive).
- Merge when: Two services always have to change code together (Tight coupling) or their data always requires absolute consistency.
Epilogue for the "Microservice Journey" Series
If you ask me: "Ultimately, are Microservices worth it?". My answer remains: YES, but with a cautious attitude.
We started from a Monorepo (Post 1), struggled with DBs (Post 8), learned to monitor the system (Post 2), and finally found balance in Macroservices (Post 18).
Software architecture is not a religion to worship. It is a toolkit. Don't choose Microservices just because they're "cool" or because Google uses them. Choose them when the pain of the old Monolith has become greater than the pain of managing a distributed system.
Our ultimate goal is to ship value to users, not to draw the most complex architectural diagram possible.
Thank you for joining me through these 18 "blood, sweat, and tears" articles. I wish you well in building sustainable and powerful systems!
Lessons Learned
Don't be afraid to go back and merge services if you see that you split them wrong. In engineering, admitting mistakes and having the courage to refactor is the sign of a mature engineer.
Series • Part 18 of 20