1. Map Your Current Microservices
Create a visual or list-based map of:
Inter-service communications (REST, events, etc.)
This will help you see overlaps and redundancies.
2. Spot the Smells (Signs of Too Many Microservices)
Look for services that:
Only wrap a database table (CRUD-only services)
Are tightly coupled to others (e.g. always deployed together)
Communicate too frequently (chatty services)
Have no real domain meaning (e.g., NotificationDbService)
Are owned by the same team and change together
These are candidates for consolidation.
3. Group by Business Capability
Re-cluster services by business capabilities rather than technical responsibilities.
Example:
UserProfileService, UserSettingsService, and UserNotificationPreferencesService might be better off as one UserAccountService.
4. Review Service Interactions
If two services:
Call each other frequently
Are part of the same user flow (e.g. CartService + CartPricingService)
They probably shouldn't be separate unless there's a good scaling or ownership reason.
5. Review Teams & Deployment
Ask:
Are multiple services always deployed together?
Are they maintained by the same team?
Do they require coordination on every change?
If yes, consider merging them.
6. Check for DDD Violations
If your services don’t align with business boundaries or bounded contexts, you're likely over-segmented.
🧩 What to Merge vs What to Keep
Criteria
Merge
Keep Separate
Different scaling requirements
Let’s say you have:
You could consolidate them into a single NotificationService with strategy pattern or plugins to handle different channels.
Use tools like Kiali, Zipkin, or Jaeger if you’re on a service mesh (Istio) to visualize service traffic and dependencies.
For static analysis: build service dependency graphs based on your codebase or OpenAPI specs.
Last updated
