Beyond Sharding: How Service Unitization Solves Unlimited Scaling

Typical Service Evolution Path

Developers often start with a monolithic application built on frameworks like SSM or SSH. As business grows, they move to RPC‑based services to enable horizontal scaling, assuming statelessness is enough.

When traffic continues to increase, services become more complex and many requests no longer need a database connection, only a cache, leading to the adoption of sharding and database partitioning.

However, simply splitting databases does not solve the core problem of excessive database connections.

In an RPC architecture, each service connects to every database instance via middleware (e.g., ShardingJDBC). If you have 30 RPC services, each with a connection pool of 8, and 3 MySQL instances, you end up with 240 connections per MySQL. Since MySQL defaults to a maximum of 16,384 connections, scaling beyond roughly 2,048 services becomes impossible.

Adding a proxy in front of the services does not help, because the proxy itself is limited by the same connection ceiling.

Thus, the bottleneck is that every RPC service must maintain connections to all databases, causing connection counts to grow with each new service instance.

Unitization

Unitization avoids the need for each service to connect to every database. By partitioning databases (e.g., by range) into N shards and ensuring each service only connects to a single shard, you can double the number of services by also doubling the number of database shards.

The prerequisite is that a request’s target database can be determined before it reaches the service, typically via a deterministic rule such as hashing the user ID. This rule is distributed via a configuration center so all components share the same mapping.

When a user’s request arrives, DNS or a front‑end router already knows which service (and thus which database shard) should handle it, eliminating the need for the service to maintain connections to unrelated databases.

Below is a diagram illustrating the rule‑based routing:

With this approach, unlimited scaling becomes feasible because the number of database connections per service remains constant regardless of how many services are added.

Conclusion

The article walks through the evolution from monolithic applications to RPC services, sharding, and finally unitization, showing that sharding alone cannot achieve unlimited scaling due to connection limits. Unitization resolves this issue but introduces additional complexity, and further topics such as high‑availability and multi‑region active‑active setups remain for future discussion.