Unless I’m mistaken the CachingEventSourcingRepository implementation is somehow a write-through implementation. It means it stores the data into the cache then tries to updates the event store. If the event store write fails for whatever reasons, there is a compensation to remove the cached data.
This might create to me potential issues if between the read and the remove, another concurrent client tries to do a read without any specific locking.
Don’t you think it might make sense to implement the way to choose the strategy? Personally I would be more interested in an approach where the cache is updated after the event store was updated.
What’s your opinion? Is there anything I’m missing?