Why Sharding Alone Cannot Achieve Unlimited Scaling and How Unitization Solves Database Connection Limits

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 problem of service expansion.

1. Typical Evolution Path of a Service

We start from the very beginning.

Monolithic Application

Most startups begin with SSM/SSH‑style monoliths – a stage every developer has experienced.

RPC‑Based Application

When the business grows, horizontal scaling is needed; making services stateless allows simple scaling (see image).

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

Most companies reach this stage, and Dubbo was created to solve these problems.

Sharding (Database Partitioning)

If a product becomes popular, data grows rapidly and SQL operations slow down, the DB becomes a bottleneck. Sharding by ID hash or range can help (see image).

It seems the problem is solved: no matter how many users or how high the concurrency, we just keep adding DB instances and application instances.

However, this architecture does not truly solve unlimited scaling.

The core issue is excessive database connections caused by RPC applications that must connect to every database through middleware (e.g., Sharding JDBC).

For example, an RPC service that needs to talk to three MySQL instances, multiplied by 30 services, each with a pool of 8 connections, results in 240 connections per MySQL. Since MySQL defaults to 100 max connections (max 16384), exceeding about 2048 services will hit the connection limit, preventing further scaling.

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

Thus, the problem lies in “every RPC service connects to all databases”, which forces connection counts to grow with each service instance.

2. Unitization

Unitization, often mentioned in conferences with buzzwords like “two‑site three‑center” or “multi‑active‑region”, addresses the “too many DB connections” issue.

The idea is simple: prevent applications from connecting to all databases.

Suppose we split a logical database into 10 physical shards and have 10 services, each connecting to a single shard. When the number of services grows to 20, we further split the 10 shards into 20, ensuring each service still connects to only one shard. This way, no matter how many services we add, the per‑DB connection count remains bounded.

The prerequisite is that a request’s target database must be determinable before it reaches the application, typically via DNS or a hash‑based routing rule broadcasted from a configuration center.

For instance, routing can be based on a user‑ID hash, ensuring all components use the same rule to reach the correct database (see image).

With this approach, unlimited scaling becomes achievable.

3. Conclusion

The article traced the evolution from monolith to RPC to sharding, showing that sharding alone cannot solve the “unlimited scaling” problem because of database connection limits. Unitization resolves this issue, albeit introducing additional complexity, and also raises new concerns such as single‑point‑of‑failure for the databases themselves.