Tencent TDMQ: Cloud‑Native Message Queue Architecture and Implementation

This article summarizes a presentation by Liu Dezhi, an expert engineer from Tencent's TEG Technical Committee, on the design of TDMQ – a next‑generation cloud‑native message queue built on Apache Pulsar with a storage‑compute separation architecture.

Financial‑grade cloud‑native MQ requirements : Multi‑language, multi‑protocol support, unlimited topics and consumers, and rapid on‑demand scaling are essential for modern message queues.

Tencent Billing background : The Tencent Billing platform processes billions of transactions daily for over 180 countries/regions, supporting both ToC (e.g., user top‑ups, game purchases) and ToB (e.g., advertising, cloud services) scenarios. It handles massive traffic, requires high reliability, strong consistency, and horizontal scalability.

MQ usage scenarios in Tencent Billing : Online services (asynchronous processing, compensation for TCC/saga failures, notification, real‑time transaction logs) and offline near‑real‑time services (cross‑region reconciliation, data aggregation). Additional needs include data synchronization channels for multi‑source DB sync and massive consumer groups.

1. Functional architecture of TDMQ : Provides typical queue features (high consistency, high reliability, delayed messages, ordered messages) and supports both Queue and Stream consumption models. It offers multi‑protocol SDKs (Java, C++, Go, Python, Node.js) and compatibility with Kafka 2.0+ and RabbitMQ 4.0+ clients, facilitating migration and integration with big‑data ecosystems such as Flink and Spark.

2. Storage‑separation architecture : Built on Pulsar’s two‑layer design – stateless Brokers handle routing and control, while Bookies store data as ledgers. Brokers do not store state; they coordinate topic placement via ZooKeeper. Bookies store immutable ledgers that can be migrated at shard granularity, enabling independent scaling of compute and storage resources.

3. Consistency model : TDMQ adopts a quorum‑based approach similar to Raft. Writes require Ensemble Size (E), Write Quorum (W), and Ack Quorum (A). The system ensures ordered message IDs (ledger‑id + entry‑id) and uses fencing to prevent split‑brain scenarios.

4. Cross‑city disaster recovery : Supports same‑city active‑active and inter‑city active‑active modes. Data is replicated across regions (e.g., Shenzhen and Shanghai) with asynchronous or synchronous replication, ensuring that at least one replica survives regional failures. Geo‑replication is configurable and protects both online payment flows and offline analytics.

5. High‑scale consumer design : Introduces read‑only Brokers to offload consumption from write Brokers. Topics are assigned to a single write Broker, but read‑only Brokers can fetch data from Bookies using metadata synchronization, allowing millions of consumers without degrading write performance.

6. DB synchronization practice : TDMQ is used as the transport layer for binlog‑based change data capture (CDC) in Tencent’s TDSQL cross‑city disaster‑recovery solution. Binlog producers run on standby MySQL instances, pushing changes to TDMQ; consumers replay logs in the target region, guaranteeing at‑least‑once delivery, ordering per row, and idempotent processing.

7. Q&A highlights : TDMQ is the unified messaging backbone for all Tencent billing services, supports multiple languages, offers stronger consistency than Kafka for financial workloads, provides delayed consumption, and includes upcoming lightweight stream‑processing capabilities.

Overall, TDMQ demonstrates a cloud‑native, highly available, and scalable message‑queue solution tailored for financial‑grade services, with a clear separation of compute and storage, robust consistency guarantees, and flexible cross‑region replication.