High Availability

Synapse does support high availability (HA).

This page explains how the HA features in Synapse work. To see how to configure them, refer to HA Configuration.

Prerequisites

For using HA, you need to have selected AxonServer as a means of storing your Synapse configuration. Refer to Storage on how to do this.

Whilst it’s possible to simply run multiple independent Synapse instances without shared configuration, this is highly discouraged and generally regarded as a bad idea.

What HA in synapse covers

Using HA in Synapse does provide you with the following:

  • Tolerate individual Synapse instances to go down for maintenance or crash

  • Provide a way for the different handler types to balance themselves and be re-assigned when a Synapse instance goes down.

Synapse handles the different handler types in different ways:

Command handlers

Each Synapse instance registers all configured command handlers with AxonServer. AxonServer then makes sure to send the commands to the correct handler instance via the Synapse instance used to register the handler.

Event handlers

To prevent duplication of events as far as possible, Synapse instances cooperate to register event handlers only from one Synapse instance. This allows your client application to receive events from only one Synapse instance, as long as the topology doesn’t change.

When changing synapse instances, you may see slight duplication of events delivered. This is normal and unavoidable.

When topology changes (for example when a Synapse instance crashes or a new one appears), handlers are re-assigned to available Synapse instances according to a consistent hashing algorithm. This makes sure that if a Synapse instance goes down, other instances pick up the now unassigned event handlers.

Query handlers

As with Command Handlers, each Synapse instance registers all configured query handlers with AxonServer. Again, AxonServer then makes sure to send the queries to the correct client application.

Infrastructure

To be fully high-available, it’s not enough to have Synapse set to HA. One should take the following aspects into consideration.

Axon server

Synapse instances (and other client applications directly connecting to AxonServer, like AxonFramework applications) should have the addresses of all primary AxonServer nodes in the cluster configured. This allows them to reconnect if an AxonServer node were to go down.

Synapse

Using the AxonServer as storage implementation and enabling HA allows you to tolerate synapse nodes going down and the remaining ones taking over.

Client applications

If you use Synapse to publish events, commands or queries, make sure that your client applications know all available Synapse instances and can retry if one should go down. Alternatively, add a reverse proxy with multiple upstream destinations for the publish endpoints.

Further, have your client applications run in a highly available manner. If Synapse is available but your client application goes down, you didn’t win much in regards to availability. Further, since registered handlers in Synapse only can have one configured URL, make sure to place a reverse proxy with multiple upstream destinations in between Synapse and the client applications it’s calling. Thereby, synapse can retry calling endpoints if one of the instances of your client application were to go down.