From Monolithic to Unitized Architecture: Overcoming Unlimited Scaling Limits

Preface

As a newcomer, I often wondered about JDK API, NIO, JVM, and after a few years of work I started questioning service availability and scalability, especially the classic problem of service expansion.

Normal Service Evolution Path

Most startups begin with a monolithic application built on frameworks like SSM or SSH. When the business grows, they move to an RPC‑based architecture to achieve horizontal scaling, assuming stateless services are sufficient.

Further growth leads to complex service relationships, and many services only need cache access, prompting separation to reduce database connections. At this stage, technologies such as Dubbo are introduced.

If traffic continues to surge, database operations become a bottleneck, leading teams to adopt sharding (by ID hash or range) and create multiple physical databases.

However, simply adding more databases does not solve the problem because each RPC service still maintains connections to every database. With a large number of services, the total number of MySQL connections quickly exceeds the server limits, and adding a proxy does not help because the proxy itself is subject to the same connection ceiling.

Unitization

Unitization addresses the “too many database connections” issue by ensuring that each application instance connects only to a single database shard. When the number of applications grows, the number of shards is increased proportionally, keeping the per‑application connection count constant.

This requires a routing rule—often based on user‑ID hash and distributed via a configuration center—so that a request is directed to the appropriate database before the application processes it. The rule is enforced at the DNS or load‑balancer level, guaranteeing that each request reaches the correct shard.

With this approach, unlimited horizontal scaling becomes feasible because the connection pool size per service remains bounded.

Conclusion

The article demonstrates that while sharding and partitioning alleviate some scaling pressures, they cannot alone achieve unlimited expansion due to connection limits. Unitization solves this problem but introduces additional complexity, and further considerations such as high‑availability and single‑point‑of‑failure remain.