CODEWITHSUNDEEP
cqrsevent-sourcingaxonaxon-framework
Tomás Juárez
Tomás Juárez

Reputation: 1514

Distribute events over the network

I'm trying to use Axon framework for an event sourcing-based application and I need to publish certain types of events so other services can be aware of that for specific purposes (statistics, email servicing, etc.). The problem is that, from Axon's documentation, services should share the event store to subscribe to these events (see here). This is a violation of the microservice architecture because services are sharing the DB, although the schema will not change over time, because it's an event store. Another option is to set up Kafka or another message broker like RabbitMQ, ActiveMQ or any other AMQP compatible broker. However, that means that those message brokers would also be responsible for persisting in the event, which is not ideal. My question is: is there any way to persist the events in a non-shared datastore but also publish the events to another service in a topic or a queue?

Thanks.

Upvotes: 0

Views: 352

Answers (2)

Steven
Steven

Reputation: 7275

What's key to take into account, is that in a microservices landscape, some services do belong to the same context, and others do not. The ones that do, would conceptually be part of the same (bounded) context. The services within a context furthermore could just as well be regarded as a single service. From that perspective, sharing the data source/schema should not be problematic.

It's as soon as the scope broadens and you have distinct contexts, which I assume you have in your setup, Tomás, then you would introduce some kind of broadcast mechanism for your events.

The ideal choice for a system that would use Event Sourcing honestly is an actual Event Store. Hence, Axon Server (or EventStore.com) would be your only reasonable option, as those are Event Store database types. Axon Server also provides the means to define the contexts I've just mentioned, to automatically construct distinct storage locations and message streams to keep the data separated.

The referred-to piece of documentation has some unlucky wording when it comes to Axon Server, I must admit that. I'd wager some adjustment is in place for the documentation to mitigate this confusion.

When it comes to the EmbeddedEventStore, which I assume you're using, I'd like to clear up the following. You should take that although the data source is shared, nothing states that this data source should contain your application-specific schemas. It's actually recommended to use a distinct data source just of your events. This would, as you already mention, not form a problem as there is no concern of schema mixture when doing so. You would set this up. per (earlier mentioned) context. since you definitely don't want your events between distinct contexts to be combined. It is with this setup, and the requirement to distribute events to other contexts, that the alternatives (in the perspective of a dedicated Message Router like Axon Server) AMQP or Kafka can be used.

I still agree it's not the ideal solution; that would be a dedicated Event Store implementation like Axon Server. So, let me refer to the question you've posed in your message:

is there any way to persist the events in a non-shared datastore but also publish the events to another service in a topic or a queue?

Yes, there is. Ideally, you'd use a dedicated Event Store like Axon Server. Or a diligently controlled combination of context-separated single-purpose data sources and brokers.

As you are already using Axon Framework, trying out Axon Server should be a piece of cake though, so I'd take that route.

Upvotes: 0

Phil Sandler
Phil Sandler

Reputation: 28016

You are correct that sharing the database between services would violate the principles of SOA and thus the principles of Microservices. Surprising that they suggest this in their documentation.

Here is an approach I have taken, making some assumptions about your setup: expose the events in the Event Store to outside consumers via an http endpoint (API). The API will likely allow filtering of events from a certain checkpoint/date, and also by stream/aggregate Id. Then use a message broker or ESB to broadcast notification events, which are distinct from event store events and only contain enough information to alert downstream services that something changed so that they can then query the API. The sequence would be something like:

  1. Change is made to WidgetA
  2. Main Service broadcasts a message that WidgetA changed on XX date
  3. Consuming Service receives WidgetChangedEvent
  4. Consuming Service queries Main Service's API for events with WidgetA's Id that are later than XX date

Upvotes: 0

Related Questions