You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 1, 2021. It is now read-only.
This can be achieved by allowing an EventsourceActor (= aggregate) to consume from multiple logs and only write to one of these logs. Aggregate replicas with the same aggregate id write to different logs but consume from all of them, so that distributed writes to the same aggregate id don't need to be merged into a single log. For example, with three (optionally replicated) logs, A, B and C and three aggregate replicas r1, r2 and r3:
r1 writes to A and reads from A, B and C
r2 writes to B and reads from A, B and C
r3 writes to C and reads from A, B and C
This means that replicas ri need to be recovered from three logs (instead of one) and deterministic (= totally ordered) replay is not possible any more. However, by re-ordering concurrently replayed events based on their vector timestamps, causal ordering can be achieved.
The text was updated successfully, but these errors were encountered:
This can be achieved by allowing an
EventsourceActor
(= aggregate) to consume from multiple logs and only write to one of these logs. Aggregate replicas with the same aggregate id write to different logs but consume from all of them, so that distributed writes to the same aggregate id don't need to be merged into a single log. For example, with three (optionally replicated) logs, A, B and C and three aggregate replicas r1, r2 and r3:This means that replicas ri need to be recovered from three logs (instead of one) and deterministic (= totally ordered) replay is not possible any more. However, by re-ordering concurrently replayed events based on their vector timestamps, causal ordering can be achieved.
The text was updated successfully, but these errors were encountered: