# Overview A database replication approach (also known as active-active replication) where multiple nodes act as leaders with the ability to accept writes and communicate the writes the other leaders. # Key Considerations ## Replication Topologies for Multi-leader Replication #flashcard The configuration of how writes are communicated among leaders can result in different replication topologies. Each result in different implementations of replication and the shortcomings of each should be known: ![[2024-11-20_Multi-leader Replication.png]] ### Circular Topology If you lose a node, you lose the ability to get data across all the nodes. ### Star Topology You create a single-point-of-failure in the center of the star. ### All-to-all Topology Very complex, especially in relation to [[causality]]. <!--ID: 1751507776620--> ## Effective Implementation Strategies - Modify the replication log to track which nodes have seen a write. This ensures we don't do duplicates. - Need to consider [[Conflict Resolution]] for write conflicts # Pros to Multi-leader Replication #flashcard - Can offer improved performance in a multi-datacenter configuration, since writes can be performed at the closest data center to the user, rather than going to a single data center that can accept writes - Improved fault tolerance from network and data center issues <!--ID: 1751507776624--> # Cons to Multi-leader Replication #flashcard - Introduces the complexity in order to handle [[Conflict Resolution]] <!--ID: 1751507776627--> # Use Cases to Multi-leader Replication #flashcard - In architectures that are distributed across multiple data centers, where you can have a leader in each data center. - Applications that require an 'offline mode' (e.g., calendar apps). The offline device acts as a local leader, which then must communicate updates to the other leader located in a data center when the devices come online. - This same concept applies to collaborative editing apps <!--ID: 1751507776629--> # Related Topics - [[Active-active Replication]]