Beyond Sharding: How Unitization Solves Unlimited Service Scaling

Typical Service Evolution

Projects usually start with a monolithic Java application built on frameworks such as SSM or SSH. When traffic grows, the code is refactored into stateless RPC services to enable horizontal scaling. At this stage many calls can be satisfied by a cache, so database access is isolated and RPC frameworks like Dubbo are introduced. When the volume of data and queries becomes a bottleneck, the logical database is split into multiple physical shards (by ID hash or range) and each shard is hosted on a separate MySQL instance.

Connection‑Count Bottleneck

Even after sharding, each RPC service typically maintains a connection pool for **every** physical database because the middleware (e.g., Sharding‑JDBC) decides the target shard at runtime. If there are N databases, M services, and each pool size is P, the number of connections per database becomes M × P. For example, with 3 MySQL instances, 30 services and a pool size of 8, each MySQL server must handle 240 connections. MySQL’s default max_connections is 100 and the hard limit is 16384, so when M exceeds roughly 2048 the system cannot acquire new connections and scaling stops. Adding a proxy in front of the databases does not solve the problem because the proxy also hits the same connection ceiling.

Unitization (Database‑Per‑Application) Strategy

Unitization forces each application instance to connect to **exactly one** database shard. The logical database is divided into K shards; each of the K application instances is bound to a distinct shard. When the number of services grows, the number of shards is increased proportionally (e.g., from 10 to 20) so that the connection pool size per database remains constant.

Key requirements:

Routing must be decided before the request reaches the application, typically via DNS‑based routing or a hash of the user identifier.

The routing map is stored in a centralized configuration service (such as Nacos, Apollo, or Zookeeper) and broadcast to all components to keep the mapping consistent.

Each application’s data‑source configuration points to a single physical database.

With this pattern the total connections per database stay at P regardless of how many services are added, enabling unlimited horizontal scaling of both services and databases.

Considerations

Unitization introduces operational complexity: shard creation, data migration, and monitoring must be managed.

It does not eliminate the single‑point‑of‑failure of each shard; high availability must be provided at the database layer (replication, failover, etc.).

Routing logic must be deterministic and kept in sync across all services.

Conclusion

Simple sharding cannot guarantee infinite scalability because the number of database connections grows with the number of services. By restricting each service to a single shard and scaling the number of shards together with the number of services (unitization), the connection bottleneck is removed, allowing true horizontal growth. The trade‑off is added complexity and the need for robust HA mechanisms for the individual shards.