Why Axon Server Enterprise?

Fault tolerance

Axon Server Enterprise uses the Raft Consensus Algorithm to implement a fault-tolerant distributed system. This is a well-known, documented algorithm underpinning fault tolerance in platforms such as Kubernetes and Cloud Foundry. It can handle a wide range of network and host failure scenarios while keeping the cluster available to clients and preserving integrity. Something that is verified every day in AxonIQ's testing infrastructure.

Quorum-Based Storage

When using Axon Server Enterprise, transactions will not be confirmed to the client until most of the nodes have confirmed the transaction individually. Combined with spreading the cluster nodes across data centers ("availability zones" when using a public cloud provider), this gives powerful protection against data loss.

Leader/Replica Architecture

For event storage, Axon Server Enterprise has been designed with a leader/replicas clustering architecture (as opposed to the peer-to-peer architecture as implemented in, e.g., Cassandra). At any point in time, a single node is the leader and has the responsibility to verify transactions for consistency and integrity. The replicas will store a copy of the transaction to guarantee durability. When the leader becomes unavailable, a leader election protocol will ensure that a new node takes up this responsibility. For the event sourcing use case, the leader/replica architecture is the most efficient implementation of a reliable, fault-tolerant cluster.

Horizontal Scalability

Even though Axon Server Enterprise uses a single-leader concept, many mechanisms allow for horizontal scalability. First of all, the single-leader mechanism is only used where needed, which is for event storage. For routing of command and query messages, an Axon Server Enterprise cluster functions in a peer-to-peer fashion. Also, the leader role for storing events is assigned at the context level rather than the cluster level. This means that when using multiple contexts, different nodes will take up the leadership role for different contexts, which also balances the cluster load.

Storage Space per Context

In Axon Server Enterprise, each context has its own storage space on a disk (a directory). You’ll find the standard Axon Server storage structure in this directory: event and snapshot segments with the associated index files. This clear separation gives a lot of flexibility in managing different contexts in different ways, such as retention periods, encryption, backup policies, and a storage medium (fast, expensive SSDs or slower, cheaper HDDs).