Events database

The separation of read/write schemas fits in well with an events database for the write schema. This is append only.

Operational Transformation is simplified and more efficient - inserts on sets are already independent. Events in space/time tend to maximise loose coupling.

The read schema is defined as an aggregate over the events. This fits well with functional programming (aka a fold []).

Event sourcing (ES) is a similar concept to an events database, although it falls under DDD which is all about using OO to model business processes, rather than being data centric.

But the adherents to ES/CQRS often say it shouldn't be applied too often. Udi Dahan says it should tend to be used when there is collaboration. E.g. see Udi Dahan's blog post When to avoid CQRS (2011). He says: So, when should you avoid CQRS? The answer is most of the time. He says there are many things that are not collaborative. E.g.

CQRS/ES doesn't come for free. If there is no business value in archiving all the updates then don't do it.

They note many problems introduced with ES and CQRS - for example the potential for increased complexity. E.g. with the current state a user can just fix mistakes with an update to the data. But with ES it is necessary to generate an append-only event to correct a mistake. This is like when someone requests money be transferred from their account to someone else's, but the destination account number was wrong. The fix is to create an event to mark the transaction as cancelled then create a new transaction. This is a new event.

There are issues around schema evolution with event sourcing. The best approach is probably to treat a schema change to an event as a new type of event, and deprecate the old type of event.

Anyway the point is that we are proposing separation of read/write schema (like CQRS) even when not recording events (ES). But unlike conventional wisdom - that one loses all the benefits of ES such as defining read schema as folds, in CEDA we can always define the read schema as a fold over the operations. CEDA is extremely good at supporting efficient recording of operations on data, and allowing them to persist and be sent in an efficient way, and allowing multi-master replication. It also is great for allowing exactly one in order (EOIO) processing of the operations, in order to calculate folds for reader databases.

Importantly, CEDA compresses the operations themselves. For example, assignment operations compress very well. This is done by the writer database, and allows the reader database(s) to compute folds more efficiently.

Events database isn't always appropriate

Event databases aren't always appropriate. E.g. how could a CAD drawing be regarded as an events database. Even if we treat the inserts/deletes/updates to the drawing as events, we can't expect user to generate these events without working on the aggregate (i.e. the drawing itself).