I have a mental model about how akka-persistence-cassandra works. First of all, it would be great to see this model either confirmed or corrected. Continuing from the mental model I have a particular question (below the mental model)
- Two persistent actors A and B can write different events a and b to cassandra with the same tag using akka-persistence-cassandra
- Both events a and b get a timebased UUID as offset upon the moment they are written to cassandra.
- If another persistent actor C queries cassandra using queryByTag, it queries not cassandra itself but a “materialized view” of the events which will be eventual consistent.
- If this other persistent actor C queries the materialized view, it returns a AkkaStreams stream.
- The stream contains only those events that arrive/are written “after” the last event that was emitted on the stream, or for the example: If actor C queries and receives event a, but after a was emitted on the stream, b arrives in the materialized view in cassandra with an offset that indicates that b was written before a, then b will not be emitted on the stream.
- It is possible to give these late-arriving events some more time by tweaking the property eventual-consistency-delay.
- However, this is only best effort. By using the eventual-consistency-delay, you minimize the chances of missing an event, but there still is a chance that an event arrives too late.
Is this model correct or flawed?
_Is it correct that the setting eventual-consistency-delay is replaced in the latest version with gap-timeout and offset-scanning-period?
- Different persistent actors in different microservices kan write different (broadcast)events in cassandra. All these broadcast events get the same tag.
- All these broadcast events also get an offset upon arrival in cassandra, which in the case of akka-persistence-cassandra is a timebased UUID.
- The same or other microservices are interested in some of these broadcast events. They “listen” for broadcast events in which they are interested by performing a query by tag and filtering out the event types in which that microservice is interested.
- I see however that (without specifying an eventual-consistency-delay) some messages are not picked up by the listener (they are not returned by the akkaStreams stream). The missing message however is present in cassandra.
- In the application, all broadcast events have to be delivered at least once (no prob if they are delivered twice or more)
- In the application, all microservices can cope with out of order events. So the arrival order in cassandra is not that important
Is it possible to configure, tweak or design the listeners in such a way, that all broadcast events with the same tag are eventually emitted on the Stream at least once?