How We Scaled a SaaS ERP with Cloud‑Based Database Sharding on Alibaba Cloud

Architecture Overview

The SaaS e‑commerce ERP service is deployed entirely on Alibaba Cloud. The web tier uses SLB (Server Load Balance) as the entry point, distributing traffic across multiple ECS (Elastic Compute Service) instances. Data storage relies on an RDS (Relational Database Service) cluster, while shared, less‑time‑critical data resides in OCS (Open Cache Service).

Why Sharding Is Needed

When user growth accelerates, a single database cannot handle the volume and write‑read load. The team therefore prioritized database sharding (both horizontal and vertical) to keep costs low, enable elastic scaling, and distribute read/write traffic evenly.

Horizontal Sharding (By User)

Data is split across multiple identical schemas based on a business key (user_id). Each shard contains the same tables, and the user table serves as the primary routing reference. A simple algorithm such as user_id % N (where N is the number of shards) determines the target database, with more sophisticated load‑aware routing possible.

DBWrapper Layer

To keep the business layer unaware of the underlying sharding, a DBWrapper sits between DAO and JDBC. It exposes unified CRUD interfaces; internally it decides which RDS instance to connect to based on routing information stored in a dedicated router database.

Vertical Sharding (By Business Domain)

Tables with high coupling are grouped into separate databases. This reduces cross‑shard joins and isolates the impact of heavy‑traffic tables. Vertical sharding also simplifies locating the primary business table, which aids subsequent horizontal sharding.

Combining Horizontal and Vertical Sharding

Both strategies are used together: vertical sharding first isolates domains, then horizontal sharding distributes the load within each domain. This approach minimizes implementation cost while providing flexible scaling paths.

Operational Optimizations

Delay loading of rarely used data to reduce DB pressure.

Cache static dictionaries and low‑latency data in OCS.

Use connection pooling, batch queries, and batch commits.

Apply optimistic locking instead of pessimistic locks for high concurrency.

Break large transactions into smaller units or use asynchronous commits.

Prefer simple queries and avoid cross‑shard joins; when necessary, perform batch reads and assemble results in the application layer.

Performance Tuning Tips

Choose compact field types (e.g., date instead of datetime, tinyint for flags) to reduce row size.

Create indexes on high‑cardinality columns, but limit the total number of indexes to avoid write penalties.

Use covering indexes so queries can be satisfied from the index alone, avoiding table lookups.

Practical Takeaways

The team found that early adoption of cloud services (elastic ECS, pay‑as‑you‑go SLB, managed RDS) eliminated the need for physical hardware maintenance and allowed rapid capacity adjustments during traffic spikes such as Double‑11 sales.

When the native RDS solution lacked built‑in distributed transaction support, the team built its own sharding and routing logic. With the later release of Alibaba Cloud DRDS, future projects can skip custom sharding implementations.

Overall, the combination of cloud infrastructure, systematic sharding, and disciplined application‑level optimizations delivered a cost‑effective, highly available SaaS platform capable of handling massive user growth.