From Monolith to Unitized Architecture: Overcoming Unlimited Scaling Limits of Sharding

Normal Service Evolution Path

Initially, many startups start with monolithic architectures such as SSM or SSH, which most developers have experienced.

As business grows, services are horizontally scaled using RPC; the goal is to keep services stateless. However, when the number of services and databases increases, each RPC application may need to maintain connections to multiple databases, leading to connection pool exhaustion.

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

Sharding and Its Limits

When data volume grows, developers often consider database sharding (splitting by ID hash or range) to alleviate SQL performance bottlenecks.

Although sharding can increase database capacity, it does not solve the core issue: each RPC application still needs to connect to every database shard, quickly exhausting MySQL’s connection limits (default 100, max 16384). When the number of applications exceeds a few thousand, further scaling becomes impossible.

Unitization

Unitization proposes that each application connects only to a single database shard rather than all shards. By partitioning the logical range into N databases and assigning each of the N applications to one shard, scaling the number of applications simply requires further splitting the databases, keeping the connection count per application constant.

The prerequisite is that a request’s target database can be determined before the request reaches the application, typically via a deterministic rule such as hashing the user ID and broadcasting the rule through a configuration center.

This approach eliminates the “unlimited scaling” bottleneck caused by excessive database connections.

Conclusion

The article walks through the typical backend evolution from monoliths to RPC services and sharding, demonstrating that sharding alone cannot achieve unlimited scalability. Unitization, while introducing additional complexity, resolves the connection‑limit problem and paves the way for further discussions on high‑availability and multi‑active data centers.