Sharding

← Previous Chapter: Part 3: Caching Strategies & Redis/Valkey | Series Hub: System Design Masterclass | Next Chapter: Part 5: Asynchronous Messaging, Kafka KRaft & Event-Driven Systems → Prerequisite: Read Part 3: Caching Strategies, Redis/Valkey & Stampede Prevention to understand how memory caching shields databases before scaling storage horizontally. Answer-first: Scaling relational databases beyond vertical hardware limits requires horizontal sharding by consistent tenant keys, managing read-replica replication lag with GTID session tracking, and migrating toward Multi-Raft distributed SQL engines. Deploying Vitess VTGate or CockroachDB eliminates the single-node storage bottleneck while preserving ACID guarantees and sub-20ms P99 commit latencies across distributed clusters. ...

← Previous Chapter: Part 8: Saga Pattern & Distributed Transactions in Go | Series Hub: System Design Masterclass | Next Chapter: Part 10: Observability, Continuous Profiling & Pprof in Go → Prerequisite: Read Part 8: Saga Pattern & Distributed Transactions in Go to understand distributed consistency models before engineering dynamic key partitioning and topology rebalancing. Answer-first: Consistent hashing minimizes partition rebalancing overhead during distributed node scaling by mapping keys and nodes onto a circular continuum using virtual nodes and monotonic hashing algorithms like Ketama or Google Maglev. When cluster membership changes, only K/N keys are migrated, preventing catastrophic cache stampedes and balancing partition variance to within three percent. ...

Answer-first: Scaling MySQL writes beyond the 12,000 TPS single-primary InnoDB fsync ceiling mandates choosing between middleware clustering (Vitess) or application-layer routing (GORM Sharding). Vitess provides transparent SQL scatter-gather and zero-downtime VReplication resharding at the cost of operational proxy overhead, whereas GORM Sharding achieves zero-proxy microsecond execution bounds at the expense of rigid schema partitioning. When an engineering organization scales beyond millions of active transactions, a monolithic relational database instance inevitably becomes the single biggest systemic bottleneck in the entire software architecture. While read traffic can be scaled horizontally almost indefinitely by attaching read replicas behind a load-balancing proxy like ProxySQL, write traffic hits an unyielding physical ceiling on a single MySQL Primary instance. ...

MySQL Sharding Alternatives: Vitess vs TiDB Guide Answer-first: TiDB is the leading open-source MySQL sharding alternative, replacing fragile application-level sharding logic (Vitess, GORM Sharding) with an auto-partitioned Distributed SQL architecture. By distributing 96MB Raft Regions across TiKV storage nodes and utilizing the Percolator distributed transaction protocol, TiDB delivers horizontal write scaling, cross-node ACID transactions, and zero-downtime online DDL while maintaining 100% MySQL wire compatibility. Prerequisite: Basic knowledge of MySQL replication, sharding concepts, and Go database connectivity. ...