From Monolith to Unitization: Solving Unlimited Scaling Issues in Backend Services

Preface

As a newcomer, I often wonder about JDK APIs, NIO, JVM, and after a few years of work I start questioning service availability and scalability, especially the classic issue of service expansion.

Typical Service Evolution Path

We start from the very beginning.

Monolithic applications – most startups begin with frameworks like SSM or SSH; virtually every developer has experienced this.

RPC applications – when the business grows, horizontal scaling becomes necessary; scaling is simple as long as services remain stateless.

As the business expands further, service relationships become complex and many services only need cache access, not the database, leading to a separation that reduces precious DB connections (see image).

When the product becomes popular and data volume grows, SQL operations slow down and the database becomes a bottleneck, prompting sharding (see image).

At this point it seems that unlimited scaling is achieved by simply adding more DB instances and application nodes, but the reality is different.

The core issue is excessive database connections caused by each RPC service connecting to every database through middleware (e.g., ShardingJDBC). For example, with 30 RPC services each holding 8 connections to 3 MySQL instances, the total connections quickly exceed MySQL's default limits, preventing further scaling.

Adding a proxy does not solve the problem because the proxy itself is limited by the same connection ceiling.

Thus the bottleneck lies in “every RPC service must connect to all databases,” which increases connection counts as services scale.

Unitization

Unitization, often mentioned alongside terms like “two‑data‑centers‑three‑zones” in high‑level conferences, addresses the excessive connection problem by ensuring each service only connects to a single database.

By partitioning the logical range into 10 databases for 10 services, and later expanding to 20 databases for 20 services, we can keep the connection count per service constant regardless of horizontal growth.

The prerequisite is that the request’s target database can be determined before the request reaches the service, typically via a rule such as hashing the user ID and broadcasting the hash rule through a configuration center.

With this approach, unlimited scaling becomes feasible.

Conclusion

The article traced the evolution from monolith to RPC to sharding and demonstrated that sharding alone cannot solve unlimited scaling due to database connection limits; unitization offers a viable solution, albeit with added complexity, and also raises further considerations such as service availability and single‑point‑of‑failure in databases.