Can Sharding Alone Scale Your Services? Exploring Unitization for Unlimited Growth

Preface

As a junior developer I often wonder about JDK APIs, NIO, JVM, and after a few years of experience I start questioning service availability and scalability, especially the classic problem of service expansion.

Typical Service Evolution Path

We begin with the simplest form.

Monolithic applications – most startups start with frameworks like SSM or SSH; virtually every developer has built one.

RPC‑based services – when the business grows, horizontal scaling is needed. Making services stateless allows simple scaling, as shown in the first diagram.

As the system expands, service relationships become complex and many services only need cache access, not a database. This leads to a separation layer that reduces precious DB connections.

Most companies reach this stage, and frameworks like Dubbo are introduced to address it.

When a product becomes popular, data volume and SQL latency increase, turning the database into a bottleneck. Sharding (by ID hash or range) seems like a solution, as illustrated below.

It appears that unlimited scaling is achievable: add more users, increase concurrency, and simply expand the database and application layers.

However, the article’s title asks whether sharding alone can truly solve unlimited scaling, and the answer is no.

The core issue mirrors RPC problems: excessive database connections.

In RPC architectures, middleware hides the actual database target from the application, but the middleware still needs to maintain connections to every database instance (e.g., ShardingJDBC). If an RPC service connects to three MySQL instances and there are 30 such services, each with a pool of 8 connections, the total connections reach 240 per MySQL. MySQL’s default max connections are 100, and the hard limit is 16384, meaning that beyond roughly 2048 services the system cannot acquire more connections.

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

Unitization

“Unitization” is a buzzword often mentioned alongside concepts like “two‑data‑center, three‑center” or “multi‑active‑active”. Here we focus solely on the “too many DB connections” issue.

The idea is simple: prevent each application from connecting to every database.

Assume we initially split data into 10 shards and have 10 applications, each connecting to one shard. When the number of applications grows to 20, we further split the 10 shards into 20, ensuring that each new application still connects to only one database. This approach scales the number of applications without increasing per‑database connection counts.

Prerequisite: the request’s target database must be determinable before the request reaches the application, typically via a rule derived from the user’s ID hash and distributed through a configuration center.

In practice, a rule such as “user‑ID hash → specific shard” is broadcasted, allowing all components to consistently route requests to the correct database, as shown in the diagram below.

With this strategy, unlimited scaling becomes feasible.

Conclusion

The article traced a typical backend evolution from monolith to RPC, demonstrated that sharding and partitioning alone cannot resolve the “unlimited scaling” problem due to connection limits, and presented unitization as a viable solution, albeit one that introduces additional complexity. It also notes that while unitization solves the scaling issue, it does not address single‑point‑of‑failure concerns in the database layer.