Thoughts on RabbitMQ Streams for Eventsourcing in ServiceStack

Hi there,

Just a question on a contentious topic.

I know that in recent ServiceStack releases there has been some work done around using a “Logging” system for “light” even sourcing. What are your thoughts on using something like RabbitMQ Streams to provide a more expansive and robust event sourcing platform for ServiceStack hosts? I imagine that consumer services would consume messages from the stream to populate a redis cache (or something similar) - which would provide some interesting options in terms of service versioning, scale-out, auditing, time travel etc.

Given the architectural guidelines that ServiceStack embraces - would you say that these types of systems are antithetical to the “ServiceStack canonical architecture”, or congruent to it?

PS: obviously event-sourcing is an architectural choice would would need to be justified with value on a case-by-case basis, rather than blindly adopted as a best-practice…I’m more interested in the compatibility of the approach with ServiceStack than trying to assert that this is a one-size-fits-all approach to distributed system development :slight_smile:

To be honest you’re better asking off asking Event Sourcing proponents as I don’t really believe in Event Sourcing, I like their executable replayable properties but I dislike changing your entire development model to push everything through events which is why the “light” Executable Crud Audit Events just enables the replayability without sacrificing the development model.

1 Like

Thanks Demis - you answered my question in an indirect manner :slight_smile:

1 Like