A multi-node, multi-tenant, multi-context, zero-configuration event store and message router
Why Axon Server Enterprise?
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.
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.
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.
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).
September 28th, Amsterdam
Join us for the AxonIQ Conference 2023, where the developer community attends to get inspired by curated talks and networking.
September 27th, Amsterdam
The event to collaborate, discuss, and share knowledge about techniques, tools, and practices for building complex, distributed event-driven applications.