High‑Availability Architecture for Weibo Paid Reading and Tipping Services

The presentation introduces the booming content‑monetization market and explains how Weibo's paid reading and tipping services, launched in 2014, have grown to handle billions of requests, requiring robust internet‑finance support.

It outlines a layered architecture consisting of an access layer, service layer, transaction system, data layer, and business layer, designed to separate financial transaction concerns from service performance and application development.

The data layer uses traditional sharding and table partitioning on SSD storage, providing high throughput even when a bug directed all traffic to the primary database.

Asynchronous design is heavily employed: after a payment or refund, the transaction system notifies downstream services (paid reading, tipping) via reliable message queues such as MetaQ or Notify, allowing the transaction system to focus solely on order data and greatly increasing concurrency.

Comprehensive monitoring covers capacity (CPU, MySQL, Memcached, Redis), error detection, and anomaly alerts to manage the unpredictable growth of business partners.

A small‑amount password‑free feature was added, enabling users to authorize payments without entering a password, improving user experience while maintaining security through HTTPS, unique request IDs, and replay‑attack protection.

Idempotency is ensured by attaching a unique order ID to each request and persisting its state in the database, so repeated requests caused by timeouts are processed only once.

Distributed transaction consistency is achieved with periodic reconciliation between payment, tipping, and Weibo payment systems, handling both “payment succeeded, tipping failed” and “tipping succeeded, payment failed” scenarios via compensation mechanisms.

Security measures combine product‑level controls (T+3 fund supervision, complaint mechanisms) with technical safeguards (HTTPS encryption, unique request signatures) and monitoring alerts for abnormal transactions and asset anomalies.

The talk concludes with an invitation for further discussion and references to additional resources on large‑scale SOA distributed transaction handling.