From Monolithic to Unitized Architecture: Solving Unlimited Scaling and Database Connection Limits

In typical service evolution, companies start with monolithic applications built on frameworks like SSM or SSH.

As business grows, they move to RPC‑based services to enable horizontal scaling, assuming statelessness.

Further growth leads to complex service relationships and many services that only need cache access, prompting separation to reduce database connections, as shown in the following diagram:

When product popularity causes high traffic, databases become bottlenecks; sharding (by ID hash or range) is introduced, but this does not solve unlimited scaling because each RPC application still connects to all databases.

Given MySQL's default max connections (100) and absolute max (16384), with connection pools of size 8, exceeding roughly 2,048 applications exhausts connections, and proxies also hit the same limits.

The core issue is that every RPC service connects to every database, increasing connection count as services scale.

To address this, the article suggests “unitization”: partition databases so each application connects only to its designated database, using routing rules (e.g., user‑ID hash broadcast via a configuration center) to ensure requests are directed to the correct service and database.

By scaling the number of database shards in proportion to the number of services, unlimited scaling of applications becomes feasible, though it introduces additional complexity and does not yet solve single‑point failures.

The article concludes that unitization resolves the unlimited scaling problem but brings new challenges such as service availability and the need for further strategies.