How Akka's Active-Active Replication ensures data consistency across geographically distributed edge locations

How Akka’s Active-Active Replication ensures data consistency across geographically distributed edge locations?

This topic is based on a conversation between an anonymous user of Akka and our “Ask AI about Akka” bot in the documentation.

Akka’s Active-Active Replication ensures data consistency across geographically distributed edge locations through a mechanism called Replicated Event Sourcing. This mechanism is designed for entities that can be updated in more than one geographical location, such as edge Point-of-Presence (PoP) and different cloud regions. It allows for patterns such as active-active and hot standby to be implemented.

Here’s how it works:

  1. Entity Replication: Each entity in the system has an identity and there can be more than one instance of the same entity. These instances can have replicas in other locations. These replicas are not just read-only caches, they are truly autonomous entities that can handle both read and write operations of the entity. This is why it’s called active-active because the entity replicas can handle concurrent updates at multiple places at the same time. This ensures low latency and high availability for multi-region, multi-cloud, and cloud-edge topologies.
  2. Event Replication: Changes to the entity are captured as events, which are then replicated to corresponding entity replicas at other locations. The updates are sent to the other replicas asynchronously, which means that the replicas don’t have to be connected to each other all the time. If they lose network connectivity for a while, the events will be replicated later, when they are connected again. Akka automatically takes care of this reliable event replication mechanism.
  3. Conflict Resolution: The application logic for updating the entity state from the events must be designed to handle concurrent, independent, updates from other replicas. The end goal is that the state would eventually become the same at all replicas after receiving all events. This is achieved by using Conflict Free Replicated Data Types (CRDTs) or application logic.
  4. Filtering: Filters can be used to define that a subset of the entities should be replicated to certain locations. The filters can be changed at runtime. This helps in controlling network traffic and storage redundancy at large scale.
  5. Resilience: If there is an outage at one location, the traffic can be routed to another location with replicas of the same entities. This ensures better resilience and higher availability.

You can learn more about Akka’s Active-Active Replication in the documentation.

Sources:

1 Like