I’m currently building an event-sourced microservice architecture using Axon, and I’m wondering what would be the best way to reliably publish to an event log. I plan to use Kafka to publish my events, but even then there is a remote possibility the event store and Kafka might become out of sync (e.g., power outage after Kafka publish and before DB commit).
Ideally, I would still like the ability to replay events so that different microservices could rebuild their projections. Couple of options come to mind:
If microservice X is interested in microservice Y’s events, X could create a trackingeventprocessor against Y’s event store (would need to share db connection string) and source its events from there. I guess this eliminates the need for Kafka? This sounds like a very coupled solution infrastructure wise.
Create a trackingeventprocessor in each microservice that has the sole responsibility to publish to Kafka through an event handler. My understanding is that only persisted events would then be published and it offers a possibility for event replay through token reset.
I’m also trying to work around the issue of our Kafka infrastructure only having a finite retention period.
Might be crazy ideas, but I’d like to explore all options before introducing other options like change data capture.
this is exactly what an Event Store is good at. Yes, it also eliminates the requirement for Kafka (for this purpose), which should also be a good thing. Simpler infrastructure will take you a lot further.
If, for another reason, you’d still want to publish to Kafka as well, a Tracking Processor would be the most reliable approach. As Kafka retains messages, you could even use Kafka to retrieve the last successfully published message and really ensure all messages are eventually published.
We generally recommend using a single Event Store per bounded context (as defined by Domain Driven Design). A single bounded context could consist of a single microservices, but quite commonly they’re a group of somewhat related services that share a common language. In such case, it’s safe for them to use eachothers events. When sharing events with other services, you’d want to be a bit more careful. Any event you publish means a contract with another party. Change to event structure then depends on the flexibility of these other parties.
In AxonServer (Enterprise), we support multi-context approaches, for exactly this reason. Publishing an Event to a context, only makes the event available for services that have permissions to read from that context. Components may “promote” messages to other (more public) contexts, optionally doing a modification of the message’s structure.