DB Replication Sharding
Overview
Use this skill to design data topology that scales safely without hiding consistency and operability costs.
Scope Boundaries
- Throughput, storage, or availability limits exceed single-instance capacity.
- Read/write scaling requires replication or partitioning.
- Regional or tenant growth pressures topology redesign.
Core Judgments
- Replication mode and consistency expectations for read paths.
- Shard key strategy and future rebalancing feasibility.
- Cross-shard query/transaction requirements.
- Failover behavior and recovery-time expectations.
Practitioner Heuristics
- Choose shard keys by access locality and growth distribution, not by convenience.
- Read replicas are eventually consistent systems; classify which reads can tolerate lag.
- Cross-shard joins and transactions should be exceptions with explicit ownership.
- Topology decisions must include operational playbooks for failover and rebalancing.
Workflow
- Profile read/write distribution and growth projections.
- Select replication topology by availability and consistency needs.
- Evaluate shard key candidates and hotspot risk.
- Design routing, rebalancing, and failover behavior.
- Define application-level behaviors for lag, split-brain prevention, and retries.
- Document expansion path and de-risking milestones.
Common Failure Modes
- Shard key creates unbounded hotspots as tenants grow.
- Replica lag assumptions leak into business-critical reads.
- Rebalancing is planned as manual emergency work only.
Failure Conditions
- Stop when shard key cannot support projected growth distribution.
- Stop when consistency expectations contradict selected topology.
- Escalate when failover and rebalancing are operationally infeasible.