Inside Weibo’s Third-Gen Architecture: Scaling to 140M MAU

Preface

In March 2014 Sina Weibo reported 143 million monthly active users, with 808,298 posts sent in the first minute of the new year, demanding a highly available, high‑concurrency, low‑latency backend.

The first‑generation platform used a LAMP stack with MyISAM, PHP, and Memcache.

The second generation modularized, service‑oriented, and componentized the system, replacing PHP with Java and forming an SOA architecture.

After extensive refactoring and operational experience, the platform arrived at a third‑generation architecture.

Third‑Generation Technical System

The third‑generation system employs an orthogonal decomposition model: horizontally a three‑tier structure (interface, service, resource) and vertically four layers (business architecture, technology architecture, monitoring platform, service‑governance platform).

The diagram splits the system into 12 zones (3 × 4), each representing the intersection of a horizontal and vertical dimension, e.g., zone 5 focuses on the service‑layer technology architecture.

Horizontal Layer

The interface layer provides unified APIs for web pages and mobile clients, with core services for Feed, User Relations, and Messaging.

The service layer modularizes core business into atomic services (e.g., short‑link, ID generator) and composite services (e.g., Feed, Messaging) that may depend on atomic services.

The resource layer stores data models, including caches (Redis, Memcached) and persistent stores (MySQL, HBase, TFS, Sina S3).

Dependencies flow top‑down: upper layers depend on lower layers, never vice‑versa.

Server types include front‑end API servers, queue servers for write‑side processing, and storage nodes (MC, MySQL, MCQ, Redis, HBase).

Vertical Extension – Technology Architecture

To support core business, the platform built numerous middleware components, forming a comprehensive technical framework that improves development efficiency and operational stability.

Interface Layer – Web V4 Framework

The framework standardizes API development using Spring AOP, built on Jersey, and provides authentication, rate limiting, logging, degradation, and automatic serialization of beans to JSON/XML.

Service Layer Framework

MCQ Message Queue

MCQ (SimpleQueue Service over Memcache) offers FIFO messaging, persisting data to BerkeleyDB, exposing only get/set commands, and is heavily monitored via stats queue. It accelerates front‑end response time and enables asynchronous DB writes and real‑time data feeds to search, analytics, and operations.

Motan RPC Framework

Motan uses Netty as the transport, supports Hessian and Java serialization, and provides protocols such as Motan, HTTP, TCP, and MC. It offers HA and load‑balancing strategies (FailOver, FailFast, Round‑Robin, LRU, Consistent Hash) and detailed service‑call tracing, performance metrics, and standardized error logging.

Resource Layer Framework

Object Store

The object store serializes JVM objects into HBase, generating a unique ObjectID. It supports PB, JSON, and binary formats, handling dozens of object types (videos, images, articles) with metadata stored in Sina S3.

SSDCache

SSDCache acts as an L2 cache between Redis/MC and MySQL, reducing cache cost, increasing capacity, and alleviating DB pressure by handling cache‑miss penetration.

Monitoring and Service Governance

Inspired by Google Dapper and Twitter Zipkin, Weibo built WatchMan, a large‑scale distributed tracing system.

WatchMan collects foot‑print logs across all components, aggregates performance data, supports flow control, degradation, and provides low‑invasiveness by instrumenting only middleware layers (API framework, RPC framework, resource middleware).

The system enables service scaling, gray releases, traffic switching, and comprehensive error tracking.

Conclusion

The technical framework now plays a crucial role in driving platform upgrades, business development, and operational services. Future articles will delve deeper into the design principles of core middleware.