It’s not always correct to split a system into microservices.
Just like there are valid reasons to break a service apart, there are also strong reasons to keep services together — or not split them at all in the first place.
These reasons are known as Granularity Integrators.
They are the factors that make you pause before decomposing a service, or justify keeping it large.
The real skill in choosing the right service size is balancing decomposition drivers with integration drivers, not blindly following one direction.
Below are the four most important reasons to integrate services or avoid splitting them.
1. Database Transactions (ACID)
If an operation requires a strong ACID transaction across multiple parts of the system, those parts usually should not be separate services.
Example (Laravel)
Creating an Order and updating Stock must happen together.
If one fails, both must roll back.
If these operations live in separate services, you’ll need:
- Distributed transactions
- Complex compensation logic
- Higher failure scenarios
In this case, integration or a monolith is a logical and simpler choice.
2. Workflow & Choreography Complexity
Ask yourself:
Do services need to communicate heavily to complete a single business operation?
Example:-
- Order Service
- Payment Service
- Shipping Service
If every order requires constant back-and-forth communication between these services, splitting them may:
- Increase latency
- Increase operational complexity
- Make debugging much harder
High communication overhead is often a sign that separation may hurt more than help.
3. Shared Code
Do multiple services depend on the same complex logic?
Example (Laravel)
Imagine having complex validation logic reused across several services.
If you end up:
- Copying the same code everywhere
- Or creating shared services with frequent calls
Then service separation becomes noisy and fragile.
In such cases, keeping the logic together can be cleaner and more maintainable.
4. Database Relationships
Even if you can split the code — can you split the data?
Example
Entities like:
- Users
- Orders
- Payments
Often have strong relational dependencies.
If services require:
- Frequent joins
- Strong consistency guarantees
- Tight coupling at the data level
Then splitting them introduces:
- Complex synchronization
- Consistency issues
- Endless edge cases
Sometimes, the database model itself argues against microservices.
Final Thoughts
Microservices are not a goal — they are an architectural choice.
- Over-splitting increases complexity
- Over-integrating reduces flexibility
Good architecture is about balance.
You split or integrate based on real constraints and domain needs, not trends or hype.
Design for reality — not fashion.
Top comments (0)