In a quick search, you'll find numerous posts about why to develop in microservices. In recent years, this has become one of the hypes among developers, and I'm no exception. The first time I heard about this architecture type, it promised to open up an incredible range of possibilities.
The Theory
Microservices architecture was initially designed to solve scalability and maintainability problems, being used instead of the traditional monolith because it allows the system to continue operating normally even if one of its modules fails. When this service returns, it can "catch up" with lost time, not generating inconsistencies in the system's database.
The Reality
This was the essence, and the theory is beautiful, but what began to happen was the misuse and abuse of this technique. Everyone wanted to develop in microservices and claim they were developing in microservices, but in most cases, this was created:
Yes, this is a real case (unfortunately)
In this case, we can see that the modules have a strong coupling between them, which would already mischaracterize them as a microservice. The communication occurs through traditional requests, and here's where the nightmare begins:
- No visibility into service failures
- Inconsistent database states when services fail
- System-wide failures from single-point failures
What is a Distributed Monolith?
If you've encountered a scenario like this, congratulations, you've experienced a distributed monolith firsthand. A distributed monolith is a system broken into multiple parts with a high level of dependency and coupling. It can originate from a traditional monolith or a new system feature.
The Solution
The solution starts with asking the right questions:
- Do we really need these services to be decoupled?
- What is the actual scope of each service?
- What are the real dependencies between services?
Let's look at a better approach:
Improved architecture with proper service boundaries
Key Improvements
- Proper Service Boundaries: A collection service should handle all collections, not just specific types.
- Reduced Coupling: Services should be able to operate independently where possible.
- Clear Responsibilities: Each service should have a single, well-defined purpose.
When implementing microservices, it's crucial to:
- Carefully consider service boundaries
- Maintain loose coupling between services
- Ensure each service can operate independently
- Have proper error handling and fallback mechanisms
Remember, not everything needs to be a microservice. Sometimes, a well-structured monolith is better than a poorly designed distributed system.
Top comments (0)