Alexey Zimarev

The question is from which side this to be approached. - The current proto persistence has nice features like snapshot strategies. I have not implemented snapshotting yet, but if I...

Maybe I haven't made my point clear enough... Eventuous is not a tech lib for shovelling events to the store, it's a library to build business apps with tactical DDD,...

Correlation and causation id isn't easy as it would require commands to have an id. I am thinking about those too. Maybe the solution is to specify pre-defined header keys,...

Delayed ack doesn't seem to work. I get an exception that channel write is impossible because there's another write in progress. However, on my side all writes are awaited.

Closing it for now. Consumer groups support is good enough for that purpose.

The archive is more for closing business entities that aren't going to change anymore. Like when the order is fulfilled you might not need to keep it anymore. Restore in...

Ok, the design proposal is: - Archiving could be done by moving events to the archive store - Events can be copied all the time (with [Elastic connector](https://github.com/Eventuous/connector-esdb-elastic), for example),...

Yes, we were discussing this as well :) Replays will be highly problematic. However, a colleague made this point: you introduced a new feature, so you can hardly expect that...

Unachiving streams would be undesirable as it will fuck up the versioning, and create additional concerns for projections and replication of the events to the archive store (it must be...

That's why I want dev calls 😅. We were discussing those issues just two hours ago...