High Availability

High Availability

Up until this point, the architectures you have seen in this course share a potential problem scenario: ksqlDB rebooting from a cold state. ksqlDB does this by playing in changelogs, and the process can be made fast, but it isn’t immediate, so there will be inevitable downtime.

You can avoid this scenario, however, by adding more servers and configuring them for high availability. This means that if you lose servers, the remaining working nodes will be able to continue serving queries.

Consider two servers, a and b, where a has a replica of b, and b has a replica of a (replicas are on the right and their names begin with r):

The scenario depicted is a stateful operation where data is read from a stream and state is reflected in a table, which is backed by a changelog. But instead of the changelog being the end of the pipeline, a replica is constantly, aggressively, and optimistically replaying the changelog into its local stores. This is actually an identical action to replaying the changelog for a cold start, but it’s happening constantly and proactively, as opposed to all at once after an emergency. This means that when a node goes down, the replica can be substituted immediately.

This is an elegant solution: it’s easy to understand, and it builds upon existing ksqlDB functionality. It’s an eventually consistent system, meaning that the values eventually propagate from the primary nodes to the replicas. But you are able to control the staleness of pull queries from the replicas. So, for example, you can instruct ksqlDB to fail any request to a replica when its staleness is above a specific threshold.