Analyzing Service Granularity and Consolidation in Promise Microservices

Background – The author reflects on recent experiences with a large‑scale microservice deployment that involved nine applications and observed service sprawl, leading to increased maintenance cost, coordination difficulty, and inefficient resource utilization.

Problem Statement – Over‑segmented microservices create management complexity and distributed system challenges; the article aims to explore rational service granularity and effective consolidation.

Key Concepts

Modularization : Decomposing a system into independent, integrable parts to improve maintainability, reusability, and extensibility. Granularity : The size and scope of those parts; finer granularity offers flexibility but may incur performance and operational overhead.

Splitting Factors

Service Responsibility & Business Boundary : Ensure each service has a single, cohesive business capability (high cohesion, low coupling) and balance size by counting external entry points.

Fault Tolerance, Stability & High Availability : Separate high‑criticality services from lower‑criticality ones to limit fault impact and enable independent resilience strategies.

Performance & Throughput : Isolate high‑load components to prevent them from throttling other services.

Scalability : Split when future growth is anticipated, otherwise keep services coarse.

Team Size & Stability : Align service boundaries with team organization to reduce coordination overhead.

Merging Factors

Service Atomicity : Services that require transactional consistency or frequent synchronous interactions may be better merged.

Cost‑Benefit Analysis : Consider hardware, deployment, and maintenance costs; merging can reduce overhead.

Network Overhead : Excessive remote calls increase latency; consolidation can mitigate this.

Shared Code : High code sharing suggests a single service may be simpler.

Data Relationship : Services sharing the same database tables often belong together.

Change Frequency & Deployment : Services that are always released together indicate tight coupling.

Testing & Monitoring : Fewer services simplify observability and testing pipelines.

Case Study – Promise Services

The system includes:

A – Order fulfillment control center

B – Promise timing service (order‑to‑warehouse timing)

C – Promise capacity service (warehouse capacity)

D – Promise messaging service (asynchronous order tracking)

E – Persistence services (MySQL and Elasticsearch)

Analysis shows B, C, and D are appropriately separated due to distinct business concerns, while the two persistence services (E‑MySQL and E‑ES) share the same responsibility and change cadence, suggesting they should be merged into a single persistence service with proper fault isolation for Elasticsearch.

Conclusion – Service granularity is an evolving design decision that must balance technical factors, business needs, and team dynamics; thoughtful splitting and merging, guided by the factors above, leads to maintainable, performant, and scalable systems.