TDSQL Horizontal Scaling: Design Principles and Practice for Non‑Disruptive Linear Expansion

Introduction – Since the end of December last year, Tencent Meeting has released 14 versions in 40 days, expanded over 100,000 cloud VMs in 8 days, and consumed more than 1 million CPU cores. The service now supports over 10 million daily active accounts and is used in more than 100 countries.

The core database behind Tencent Meeting is Tencent Distributed SQL (TDSQL), which continuously supports rapid growth in storage capacity and performance while providing seamless, loss‑less horizontal scaling.

1. Non‑stop Lossless Linear Horizontal Scaling

To handle traffic spikes, the primary goal is to scale the system without downtime. TDSQL achieves this through rich read‑write separation, distributed transaction support, and a stateless SQL engine that can scale horizontally without limits.

2. Background and Challenges of Horizontal Scaling

Horizontal scaling splits data across multiple nodes, unlike vertical scaling which upgrades a single machine. While it removes the bottleneck of a single node, it introduces challenges such as data sharding, routing changes, rollback procedures, performance impact, and distributed transaction consistency.

3. TDSQL Horizontal Scaling Practice

3.1 Architecture

The TDSQL architecture consists of:

SQL Engine layer – shields applications from backend storage details.

Data storage layer – composed of multiple Sets (each a data unit) that can be configured with one‑master‑multiple‑replica setups.

Scheduler module – monitors and controls the cluster, handling scaling and failover without exposing complexity to the business layer.

3.2 One‑Click Horizontal Scaling Process

Initially data resides in a single Set. Scaling expands the Set count (e.g., from 1 to 256), moving shards to new nodes. The number of shards remains constant while node count grows, effectively migrating partitions.

Users can add Sets via a web UI, configure resources, and trigger automatic or manual routing switches at low‑impact times.

4. Design Principles Behind Horizontal Scaling

4.1 Shard‑Key Selection – Users specify a shard key when creating tables. Proper shard‑key choice keeps related data on the same node, reducing cross‑node traffic and improving performance. If omitted, TDSQL randomly selects a key, which may degrade efficiency.

4.2 High Availability & Reliability – The scaling workflow includes:

Data synchronization – new instances are created and synced in real time without affecting business.

Data verification – continuous catch‑up until latency is within a few seconds.

Routing update – briefly freezes writes (seconds) to switch routes safely.

Redundant data deletion – delayed deletion avoids I/O spikes.

4.3 Distributed Transactions – After scaling, data spans multiple nodes. TDSQL uses a two‑phase commit to guarantee atomicity, making distributed transactions transparent to applications, similar to a single‑node MySQL.

4.4 Achieving Linear Performance Growth – By keeping related data on the same shard, employing parallel computation, stream‑based aggregation, query push‑down, and data redundancy, TDSQL maintains near‑linear performance as nodes are added.

Conclusion – TDSQL’s architecture and scaling methodology provide a robust, loss‑less, and high‑performance solution for rapid horizontal expansion, supporting large‑scale cloud video conferencing and other high‑concurrency applications during the pandemic and beyond.