-1

I am thinking what is the best way to structure your micro-services, in the past the team I was working with used Axon Framework and PostgreSQL and each microservice had its own event store in the PostgreSQL database, then we built communication between using REST.

I am thinking that it would be smarter to have all microservices talk to the same event store as we would be able to share events faster instead of rewriting the communication lines using REST.

The questions that follows from the backstory is:

What is the best practice for having an event store Would each service have its own? Would they share the same eventstore?

Where would I find information to inspire and gather more answers? As searching the internet for best practices and how to structure the Event Store seems like searching for a needle in a haystack.

Bear in mind, the question stated is in no way aimed at Axon Framework, but more the general idea on building scalable and good code. As the applications would work with each own event store for write model and read models.

Thank you for reading and I wish you all the best -- Me

OMG-1
  • 498
  • 1
  • 6
  • 20

2 Answers2

4

I'd add a slightly different notion to Tore's response, although the mainline is identical to what I'm sharing here. So, I don't aim to overrule Tore, just hoping to provide additional insight.

If the (micro)services belong to the same Bounded Context, then they're allowed to "learn about each other's language." This language thus includes the events these applications publish and store.

Whenever there's communication required between different Bounded Contexts, you'd separate the stores, as one context shouldn't be bothered by the specifics of another context. Hence it is beneficial to deduce what services belong to which Bounded Context since that would dictate the required separation.

Axon aims to support this by allowing multiple contexts with the Axon Server, as you can read here. It simply allows the registration of applications to specific contexts, within which it will completely separate all message streams (so commands, events, and queries) and the Event Store.

You can also set this up from scratch yourself, of course. Tore's recommendation of Kafka is what's used quite broadly for Event Streaming needs between applications. Honestly, any broadcast type of infrastructure suits event distribution, as that's how events are typically propagated.

Steven
  • 6,936
  • 1
  • 16
  • 31
2

You want to have one EventStore per service, just as you would want to have one relation database per service for a non EventSourced system.

Sharing a database/eventstore between services creates coupling and we have all learned the hard way that this is an anti-pattern today.

If you want to use a event log to share events across services, then Kafka is a popular choice.

Important to remember that you only do event-sourcing within a service bounded context.

Tore Nestenius
  • 16,431
  • 5
  • 30
  • 40