In banking system demands are very tight. Database should be at least tripled, stand-by nodes should pick up master reads from failover node, writes should be accepted on a reasonble quorum, and later after recovery and rejoin should be merged, database should be able to scale even with the RAM/DISC limitations.

All this circumstances leads us to Chain Replication protocol as a simple and natural feedback to this challenge.

Chain Replication protocol was already used before in such products like Google FS, HDFS, mongodb, Cassandra, etc. They mostly provide a consistent distributed repository for event tables or for file storage. In banking industry we synchronize account balance with single end-point provider and track the transactions history log up to merging and cut-offs.

• Bizantine Chain Replication protocol
• Distributed transaction on replicas sequence
• Separate endpoints for HEART, CLIENT and SERVER protocols
• Quorum N+1 in 2N+1 for accepting writes
• Linear consistent ring hashing
• Automatic stand-by switchover
• Data sync on recovery
• High-performance non-blocking TCP acceptor
• HanoidDB backend database
• Pure and clean codebase

• Maxim Sokhatsky