# Overview A database replication strategy where all nodes are capable of accepting writes to the database (i.e., there is / are no leader(s)). # Key Considerations ## Addressing Stale Data #flashcard There are two approach often used for addressing stale data in nodes: - Read repair - when a client detects stale data in a node (i.e., it reads from 3 nodes and determines 1 has stale data) it can write the latest data to the stale node - Anti-entropy - a background process that is constantly looking for differences in data and making updates. - If this is not available in a database, there will be decreased durability for rarely accessed data - This can be implemented using [[Hash Tree (Merkle Tree)]] <!--ID: 1751507776632--> ## Quorums for Reading and Writing in Leaderless Replication #flashcard Every read and write is sent to multiple nodes. The database must be configured to determine at which point is a read or write successful in the database. This requires achieving some sort of [[Consensus]]. Generally, - If there are *n* replicas (i.e., nodes), every write must be confirmed by *w* nodes and every read by *r* nodes. - As long as *w* + *r* > *n*, then we expect to get up-to-date reads. It guarantees that across all the *n* nodes, there will be at least 1 node where the write and read overlap. - A common choice is n = 3 or 5 and w = r = (n + 1) / 2 (rounded up) - With n = 3, w = 2, r = 2 we can tolerate one unavailable node. - With n = 5, w = 3, r = 3 we can tolerate two unavailable nodes. - If w + r <= n, then you may read stale data, but you have lower latency and higher availability You can also consider [[Sloppy Quorums]] for when some of all of the *n* nodes that usually house the data are unavailable. <!--ID: 1751507776635--> # Pros # Cons # Use Cases # Related Topics