ESP Outbound Record Ordering Architecture

The following is the recommended architecture for achieving record ordering, using the ESP outbound connector.

We recommended using a separate ESP connector, as the XDR destination for every Aerospike source Database instance, running on the same host as shown in the architecture diagram.

For Kubernetes deployments, the ESP connector can be run as a sidecar to the main Aerospike Database container. For non-containerized deployments, the ESP connector can be run as a separate service on the same host as the Aerospike Database instance.

XDR is then configured with a data center, that ships to the local ESP container, like so

xdr {
  dc esp {
    connector    true
    node-address-port    localhost 8901

    namespace sessions {
    }
  }
}

The ESP connector is configured to maintain order, for different versions of the same Aerospike record, using the record-ordering configuration.

The ESP connector then is configured to ship XDR change notifications to the destination while maintaining record ordering.

This architecture prevents out-of-order delivery of different versions of the same record to the destination cluster, which can arise due to network reordering at the intermediate components.

This is achieved by

the ESP connector ensuring that at any time a single version of the same record (identified by namespace and digest) is in flight.
the number of Aerospike server instances are matched up with the ESP connector instances in a 1:1 manner. This prevents two different components from handling different versions of a record (identified by namespace and digest) simultaneously.

Caveat

Different versions of the same record can be delivered to the destination out-of-order when the source cluster composition changes. This is possible when the Aerospike cluster partition ownerships change while data is rebalancing.

note

Using the ESP load balancer in the XDR Proxy architecture causes extra latencies.

Caveat​

Caveat