Raft

📖 Bản tiếng Việt (Vietnamese Edition) Series Navigation: This is Part 2 of the Core Banking Systems Architecture Masterclass. For the complete architectural curriculum, start at the Master Overview Guide. Distributed SQL ACID Latency: TiDB, CockroachDB & Spanner Answer-first: Distributed SQL engines achieve horizontal write scalability and multi-datacenter fault tolerance by pairing Multi-Raft or Paxos replication with bounded distributed clock synchronization. However, cross-node consensus introduces unavoidable speed-of-light physical latency penalties. While local metro Raft commits complete in 2ms to 5ms, cross-region transactions (such as cross-region WAN links between financial centers) require 15ms to 45ms per commit round trip. Core banking platforms mitigate this through locality-aware range leasing, pipelined Percolator commit protocols, and asynchronous inter-region Saga choreography. ...

← Previous Chapter: Part 4 — MariaDB vs. MySQL | Series Hub | Next Chapter: Part 6 — Apache Kafka vs. NATS JetStream → Part 5: Sharded MySQL (Vitess) vs. TiDB NewSQL: Distributed ACID, Scale-Out Limits & Latency Penalties Answer-first: Sharded MySQL (Vitess) delivers unmatched sub-2ms write latency and isolated failure blast radius for clean single-shard workloads (tenant_id/user_id). Conversely, TiDB NewSQL is the definitive architecture for unpartitionable relational schemas and cross-shard queries via zero-touch 96MB Region auto-splits, trading off an 8–15ms write latency floor due to Google Percolator 2PC and Raft consensus hops. ...