Consensus

Series Navigation: This is Part 2 of the Core Banking Systems Architecture Masterclass. ← Previous: Part 1 — Double-Entry Ledger Schema | Master Curriculum Hub | Next: Part 3 — Event Sourcing & CQRS → | Pillar Hub: Go Microservices Guide Distributed SQL ACID Latency: TiDB, CockroachDB & Spanner Answer-first: Distributed SQL platforms achieve horizontal write scalability and multi-region fault tolerance by pairing Multi-Raft consensus with bounded distributed clock synchronization. However, speed-of-light propagation across geographic regions imposes unavoidable 15ms to 45ms round-trip consensus latencies. Core banking architectures mitigate these penalties through locality-aware range leasing, pipelined Percolator two-phase commits, and stale follower reads for high-throughput balance inquiries. ...

Answer-first: Distributed locking guarantees mutual exclusion across independent compute nodes. For high-throughput efficiency tasks, Redis locks with Lua release scripts suffice. However, for mission-critical financial correctness, asynchronous clock drift and GC pauses invalidate Redlock without monotonic fencing tokens; production systems require consensus-backed primitives like ZooKeeper ephemeral sequential znodes or etcd Raft leases with storage-side validation. Prerequisite: Advanced knowledge of distributed consensus protocols (Raft, Paxos, ZAB), asynchronous network failure modes, operating system process scheduling, and Redis internals is required for this chapter. ...