Scaling Databases with Distributed Sharding and Peak‑Shaving Strategies

Early project designs often underestimate long‑term growth and rely on merely expanding hardware specifications to handle increased database load, which can lead to serious performance risks.

Key problems include concurrency‑induced lock contention that limits throughput and uneven traffic patterns where peak requests cause hotspots that do not scale linearly.

To address these issues, the article proposes multiple strategies such as distributed peak‑shaving and share‑nothing sharding, which split data across many nodes to reduce lock contention.

Using a real‑world new‑retail example, the author shows how a PolarDB‑X distributed cluster can support 15‑25 TB of data, 1.5 W TPS and 20 W QPS, thereby handling massive write spikes and reporting loads.

Step 1 – Business Isolation: Separate relatively independent services (e.g., order system vs. inventory system) into distinct resources to avoid resource contention.

Step 2 – Horizontal Partitioning: Leverage PolarDB‑X’s horizontal scaling to split core tables across multiple physical RDS instances, preserving logical isolation while distributing load.

Horizontal partitioning not only increases capacity for larger data volumes and request rates but also provides elasticity, allowing the cluster to grow from 128 Core to much larger configurations quickly.

Step 3 – Reporting Solutions: Two options are presented: (1) traditional read‑write separation with a read‑only PolarDB‑X cluster and DTS syncing to ADB for heavy analytics, reducing report time from minutes to seconds; (2) using PolarDB‑X’s HTAP capability with an MPP‑based read‑only cluster, eliminating the need for DTS and handling both TP and AP workloads in the storage layer.

Additional optimizations include adding a global Redis layer for request handling, archiving cold data to OSS, and employing various caching techniques (browser/CDN, read‑write‑separated Redis, master‑slave Redis for inventory, Redis‑based message queues) to replace strong‑consistency relational requests.

The article concludes with a reminder that not all database requests require strong consistency, and that careful traffic filtering (e.g., in flash‑sale scenarios) can dramatically reduce unnecessary load.

阅读原文，跳转我的仓库地址