My starting point is the actually the outbox pattern.
To make sure the message in an outbox in only relayed once we only have one replica of the outbox service available in our k8s cluster. To be super sure, the deployment strategy of this service is set to Recreate. There should at no time be two services reading and relaying at the same time.
Now, I would say that from a High Availability perspective this is an anti-pattern, since the service failover time might be just too long.
I also know there is a leader election pattern where multiple services agree on a leader and then only the leader does certain actions. From my point of view exactly what I am looking for: have multiple replicas of the same service and only one of them reads and relays messages based on the fact that itself is the leader.
Did some googling and ended up at two 'exits':
- The reference implementation of the Go Kubernetes client library: https://github.com/kubernetes/client-go/blob/master/tools/leaderelection/leaderelection.go
- An article mentioning leader election in Apache Camel: https://developers.redhat.com/articles/2021/09/23/leader-election-kubernetes-using-apache-camel#running_camel_master_on_openshift
Now my question here. When searching through the code of the Apache Camel implementation it looks as if it is also using the Kubernetes locks as implemented in the Kubernetes client library. The client library implementation mentions that the leader election does not guarantee to only have one master though.
How does Apache Camel guarantee this?
