Achieve Seamless Second‑Level Database Scaling for High‑Throughput Microservices

Architecture Overview

In large‑scale internet systems, a typical layered architecture places a microservice layer above the database layer. The service records mappings between business databases and physical instances and routes SQL statements through a connection pool.

Ensuring High Availability

The common solution uses a dual‑master synchronous replication setup combined with keepalived and a virtual IP (VIP). Two master nodes keep the same VIP; if one master fails, the VIP automatically migrates to the surviving node, providing transparent failover.

Handling Data Volume Explosion

When data grows, horizontal sharding distributes tables across multiple instances. For example, a user database can be split across two instances (ip0 and ip1) using uid % 2 routing; the same principle extends to more shards.

Traditional Stop‑Service Scaling (Pros & Cons)

Announce downtime to users.

Stop microservice traffic.

Create 2 × n new databases with HA.

Run a migration script to copy data.

Update routing configuration from mod n to mod 2n.

Restart services.

Advantages: simple. Disadvantages: requires downtime, not HA, high operational pressure, risk of data loss on rollback.

Zero‑Downtime, Second‑Level Scaling Procedure

Step 1 – Modify Configuration

Introduce double virtual IPs on each physical machine (e.g., VIP0 → VIP00, VIP1 → VIP11) and expand the routing table from 2 to 4 shards: %2 = 0 becomes %4 = 0 and %4 = 2. %2 = 1 becomes %4 = 1 and %4 = 3.

Step 2 – Reload Configuration & Expand Instances

Reload can be performed by restarting services or sending a signal via a configuration center to re‑read files and re‑initialize connection pools. After reload, the number of database instances doubles (from 2 to 4) within seconds.

Both old %2 and new %4 routing coexist without affecting correctness because the dual‑master sync remains active.

Step 3 – Cleanup & Data Shrinkage

Convert double virtual IPs back to single VIPs.

Disable old dual‑master sync for the original shards.

Enable new dual‑master sync for the expanded set.

Delete redundant data (e.g., rows belonging to %4 = 2 on ip0) so each instance holds roughly half the original data.

Final Summary

The three‑step process—modify configuration (double VIPs and routing), reload to double the instance count, and perform cleanup to halve data per instance—enables a high‑throughput, high‑availability microservice architecture to scale horizontally with second‑level, near‑zero‑downtime.