Why Sharding Alone Can’t Scale Services Forever – The Need for Unitization

Preface

As a beginner, I had many questions about JDK API, NIO, JVM, and after a few years of work, I started questioning service availability and scalability, especially the classic issue of service expansion.

Normal Service Evolution Path

Let’s start from the beginning.

Monolithic applications – most startups start with frameworks like SSM or SSH; everyone has experienced this.

RPC applications – as business grows, horizontal scaling is needed; scaling is simple if services are stateless.

When the business grows further, service relationships become complex, and many services only need cache access, not DB, allowing separation and reducing precious DB connections.

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

If a product becomes popular, data grows, and SQL slows down, the database becomes a bottleneck, leading to sharding (by ID hash or range).

It may seem that unlimited scaling is possible by endlessly adding databases and applications, but this is not true.

The real issue is excessive database connections for each RPC application. Middleware decides which DB to access, causing each RPC app to maintain connections to all databases. With many apps, connection pools exceed MySQL limits, preventing further scaling.

Adding a proxy does not solve the problem because the proxy also has connection limits.

Thus, the architecture where every RPC app connects to every database leads to scaling failures.

Unitization

Unitization sounds fancy and is often mentioned alongside concepts like multi‑center or active‑active deployments.

Here we focus solely on the “too many DB connections” problem.

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

For example, split 10 databases into 10 applications, each connecting to one DB. When the number of applications doubles, split the databases accordingly, ensuring each app only connects to a single DB, eliminating connection‑limit issues.

The prerequisite is that a request’s target database must be predetermined before reaching the application, typically via a rule such as hashing user IDs and broadcasting the rule through a configuration center.

With this approach, unlimited scaling becomes achievable.

Conclusion

The article traced the evolution from monolithic to RPC to sharding, showing that sharding alone cannot solve unlimited scaling. Only unitization can, though it introduces additional complexity, its benefits are evident.