Martin Krasser

Here are my initial thoughts on the general architecture, constraints, implementation options and open issues. ### Architecture 1. **Master data management**. This architectural component is already in place backed by...

> One thing we must take into consideration during design is backwards compatibility. We can also achieve that with a migration tool or script. Breaking the existing schema shouldn't be...

You can create a total order without coordinating among journal actors. The simplest case is just merging the streams written by each journal actor. If the merged stream shall be...

Regarding re-ordering of events written by older journal versions, I wouldn't even try to do that but rather deliver the events for each persistent actor independently, either sequentially of interleaved....

To clarify, the aforementioned _total order_ is not necessarily wall clock time order (although it may come close).

> what is the indisputable advantage of separating master and index. It's the same advantage how all databases internally use a transaction log (= master) and derive structured tables from...

Here are some thoughts regarding data processing and representation of which I think they could solve the issues you mentioned in your previous comment. I make the following assumptions: -...

> I think it makes sense to start with #96 +1

@zapletal-martin I'm still for option 1 (one physical stream per write journal instance) > That may not be trivial and can cause significant performance issues I agree that the stateful...

Instead of looking at index tables we might also let the stream-merge processor write the (journal-id, persistenceId, sequenceNr) tuples to a local LevelDB, for example, that is private for that...