Unitized Deployment: Turning a Shared Cluster into N Isolated, Self‑Contained Units for 10M+ QPS

Problem statement : A system that scales by adding stateless application instances eventually hits a hard ceiling because all instances share a single central database. During a high‑traffic event the database connection limit is reached, slow queries pile up, and the whole site experiences timeouts, demonstrating that the true bottleneck is the shared DB and its 100% fault‑blast radius.

Why the whole‑deployment model has a limited lifespan

Initially, most systems start with a simple deployment: all apps share one large cluster, fronted by a load balancer, and connect to a single primary‑plus‑replicas database. This model is easy to operate, provides strong consistency, and can handle millions of QPS when tuned. However, its hidden premise is that only the stateless application layer can scale horizontally; the stateful data layer cannot.

The database becomes a single point of failure: connection limits, write TPS caps, and replication lag all block further growth. A diagram (see first image) shows all arrows converging on the central primary DB, highlighting the data‑consistency source and the system’s Achilles’ heel.

Unitization: splitting the shared cluster into N self‑contained units

The core idea is to pick a natural isolation dimension as a sharding key (e.g., buyer ID or user_id) and partition users into N shards, each backed by a complete service stack—access layer, application layer, cache, and its own database. This creates independent, closed‑loop deployment units.

Two key concepts:

Sharding key : Choose a dimension where most requests for a user stay within the same unit. In e‑commerce, buyer ID works; in many C‑end systems, user_id works.

Unit : Not just a set of instances or a DB shard, but a full stack (access, app, cache, DB) that can serve its assigned users without contacting other units.

Comparison diagram (second image) shows the whole‑deployment arrows converging on one DB versus unitized deployment where each unit has its own DB, eliminating cross‑unit traffic.

Handling data that cannot be sharded: RZone, GZone, CZone

Not all data fits the user‑sharding model. Transactional data (orders, carts) can be sharded by buyer, but global data (product catalog, configuration) cannot. The LDC architecture introduces three zone types:

RZone : Handles sharded, user‑isolated core transactions.

GZone : Holds globally unique data; updates are written here and replicated one‑way to read‑only copies in each unit.

CZone : Provides regional aggregation to support multi‑region active‑active deployments.

Diagram (third image) illustrates the three zones and their relationships.

Routing correction at the access layer

When a request arrives at a generic domain, the access gateway (e.g., MOSN) extracts the sharding key from the login token or request parameters, computes the target unit using the same hash/modulo rule as the data layer, and forwards the traffic. This ensures that "user request" and "user data" always land in the same unit. The routing flow is depicted in the fourth image.

Four concrete benefits of unitization

Unlimited horizontal scaling : Adding a unit adds both compute and database capacity, removing the single‑DB bottleneck.

Blast radius reduced to 1/N : Failures affect only the users in the faulty unit; with N=50 the impact drops to 2% of traffic.

Foundation for multi‑region active‑active : Units can be deployed across regions, allowing local reads/writes and region‑level traffic cut‑over.

Finer‑grained gray‑release : New versions or configurations can be rolled out per unit, limiting risk to a single unit.

These benefits are summarized in the fifth image.

Real costs and risks

Unitization is not a silver bullet; it incurs heavy engineering overhead:

High refactoring cost: Defining a global sharding key and making all core paths route by it is a massive redesign for legacy systems.

Global data handling: GZone data must be eventually consistent; cross‑unit queries (e.g., seller‑centric views) require additional async views.

Operational complexity: N units mean N environments, plus routing, cut‑over orchestration, and data‑sync pipelines.

Data correctness risk during cut‑over: Simultaneous writes can cause dirty data, so a "write‑disable window" is required to freeze writes, sync data, verify, then resume.

These points are illustrated in the sixth image.

Industry adoption

Major companies have applied unitization: Ant Financial’s LDC model (RZone/GZone/CZone), Alibaba’s e‑commerce transaction units, Ele.me, ByteDance, and WeChat. Internationally, Amazon’s Cell‑based Architecture follows the same principle of reducing blast radius.

Implementation typically combines high‑performance access proxies (MOSN), sharding middleware, and automated cut‑over platforms.

When to adopt unitization

Decision criteria:

Can you identify a uniform sharding key that lets most requests stay within a unit?

Does the ROI justify the engineering effort? Core transaction paths with extreme scalability and availability needs are prime candidates; long‑tail services may remain in GZone.

In summary, unitization trades substantial engineering and operational complexity for unlimited scaling, isolated failures, and multi‑region resilience—essential for systems targeting tens of millions of QPS and billions of users.