Unit Architecture Practice: Design, Benefits, and Implementation at Weibo

Many people focus on details, but architecture goes beyond the obvious; just as cement and sand make concrete, architecture is needed to build high‑rise systems.

There is no single truth in architecture—different services require different designs, just as different shelters need different structures.

Optimizing at the architectural level can yield orders‑of‑magnitude improvements with relatively modest effort, making a shift in thinking the most important aspect.

1. What is Unit Architecture

Unit (Cell) architecture originates from parallel computing. In distributed service design, a Cell is a self‑contained deployment that satisfies all operations for a particular partition (Shard) of data. Partitioning users by suffix, for example, creates shards, and unitizing adapts a service to fit this model.

Figure 1: Microscopic view of an onion cell – the goal of unit architecture is to make each unit work independently like a cell.

In traditional service‑oriented architecture, layers use different partition algorithms and node counts, with upper layers randomly selecting lower‑layer nodes.

Figure 2: Traditional service‑oriented architecture designed for scalability; upper nodes randomly choose lower nodes.

In unit architecture, each layer uses the same partition algorithm and the same number of nodes, and upper nodes access designated lower nodes because they are co‑located.

Figure 3: Unit architecture designed for performance and isolation; upper nodes access specific lower nodes.

2. Why Use Unit Architecture

Under performance and cost constraints, we need a method that satisfies service demands. Traditional SOA focuses on horizontal scalability of each service, but with Moore’s law hardware improvements, vertical scaling on a single machine becomes viable.

Unit architecture can achieve roughly half the machines while delivering up to a hundred‑fold performance increase, mainly due to service locality and integrated deployment.

Additional benefits include better request and resource isolation, smoother upgrades (e.g., gray releases), and improved handling of traffic spikes.

3. How We Implemented It

The transformation was applied to Weibo’s fan‑service platform (code‑named Castalia), which pushes high‑quality content to V‑users at millions of messages per second. Two representative services—user filtering and mass messaging—illustrate the changes.

Figure 4: Service‑oriented (old) architecture for commercial mass messaging.

Figure 5: Unit‑oriented (new) architecture for commercial mass messaging.

In the filtering service, the traditional approach required remote calls to fan‑service and feature‑service, incurring network overhead. The unit approach stores fan relationships and feature data locally, eliminating network latency and saving roughly 8 MB of bandwidth per million‑fan operation, reducing latency from 400 ms to near zero.

For the broadcast service, the traditional stack used MySQL, Memcache, queues, and separate machines for each component. After unitization, all four components run on a single machine, with local caching providing an additional ~20 % performance boost.

Specific Business Issues

Partitioning

All services must adopt a common partition algorithm; we partition by receiver, applying the same algorithm at every layer.

Feature and blocking services keep a full copy of their small datasets locally, relying on the fact that only data belonging to the unit’s partition is accessed.

Job Management

The architecture resembles a Scatter‑Gather + CQRS pattern: a broadcast request is scattered to all units, each handling its own partition. Front‑end machines monitor per‑unit jobs, using a persistent queue for reliability. Each unit records job state to ensure idempotent, re‑runnable processing.

Additional optimizations include CPU binding for multi‑service integration, multi‑disk designs for I/O, and master‑slave unit read‑write separation.

Source: http://www.infoq.com/cn/articles/how-weibo-do-unit-architecture

© Content sourced from the web; rights belong to the original author. Please notify us of any infringement.