Is it good idea to use event sourcing for distributed transactions?

Question

I have 2 clusters of stateful services: mongo and elasticsearch clusters. I want to keep documents for both clusters synchronized.

To me it looks like a distributed transaction problem, and I decided to try event sourcing, as it not only solves this problem, but naturally fits for my application.

I decided to use https://eventstore.org to store events, and subscribe from my backend for changes, then update my stateful clusters.

My backend is stateless and eventually it will be scaled to multiple instances, and I am afraid that each backend instance will get update from eventstore and update stateful clusters as updates may be idempotent, so I will end up with N similar documents for each write. How is usually this problem solved?

I really don't want to create a singleton subscriber for each cluster, which listens for updates, it makes this singleton a single point of failure...

Answer 1

How is usually this problem solved?

Using a singleton writer is a good solution. In this way you ensure that you don't duplicate the work and you update the stateful clusters using the events in the order they were wrote to the Event store.

I really don't want to create a singleton subscriber for each cluster, which listens for updates, it makes this singleton a single point of failure...

This can be easily mitigated because this singleton service is stateless so it can be easily restarted or even moved on another host when this fails. If you use a container orchestrator (like Docker Swarm or Kubernetes), this is very easy.