Mastering Data Sharding: Vertical & Horizontal Splitting Strategies for Scalable Systems

1. Prioritize Vertical Splitting

Typically start with vertical splitting by business modules to define database boundaries, then apply horizontal splitting on hot tables. Vertical splitting reduces coupling and enables independent optimization, while direct horizontal splitting can cause complex cross‑shard queries.

2. Consider Horizontal Splitting

When a table (e.g., orders) grows large, apply horizontal sharding. Example: a social platform hashes user_id into 16 shards, each with its own database instance.

Note: a globally unique ID generation strategy (e.g., Snowflake) and routing layer are required.

3. Business Association Principle

During horizontal splitting, keep strongly related data in the same shard. For an order system, order_id, order_item, and order_logistics are tightly coupled; placing them together avoids cross‑database JOINs and improves query efficiency.

4. Splitting Rules Must Be Stable

Once sharding keys and rules are set, avoid changing them, as modifications require costly data migration and risk errors.

Example: if user_id is hashed modulo 16 databases, changing to 32 would require redistributing all data.

Recommendation: reserve a larger logical shard count (e.g., 64) from the start.

5. Avoid Data Hotspots

Distribute data evenly across shards to prevent a single database or table from becoming a performance bottleneck.

6. Minimize Cross‑Shard Transactions

Design to avoid operations that need to access multiple shards, because distributed transactions (2PC, XA) incur high overhead and cross‑shard JOINs cause full scans and severe performance degradation.