Does your event store only serve one node?

In reply to the question from Stacy:

Does your event store only serve one node type? Or does your event store serve any and all nodes?

I did it in various ways, since different scenarios might require different deployment strategies. Here are some cases that worked out.

1 event store for multiple subdomains, hosted within the same worker process. Event Store is hosted in the same worker process as well (with in-memory cache) and accessible via direct calls to application services from these subdomains. Worked nicely.

1 event store per node for our scalable FTP proxy for Azure project. Each node writes to it's own event store (hosting the engine). Event consumers (if there are any) join events together. Technically, in this case one could have one central event store, accessible by multiple nodes, but I didn't want to bother with complex deployment at this phase of the project. Plus, more dependent servers you have - higher risk of failure and problems.

Multiple distinct applications, hosted in different nodes, with each of their own event stores. They can exchange information by sending commands or by pushing views with well-known schema to a well-known location. Event stores are kept private.

So generally I treat event store as something private to the application. In single-node projects - one event store per application, in multi-node environments - one event store per node (or have multiple nodes share the same event store in case of some partitioning and load balancing).

Obviously, this ratio does not involve various replication scenarios (e.g. master-slave), where replicas don't count towards the event store score (they still contain the same information).

Published: March 06, 2013.

🤗 Check out my newsletter! It is about building products with ChatGPT and LLMs: latest news, technical insights and my journey. Check out it out