Consistency

ElectricSQL provides transactional causal+ consistency with rich-CRDTs. ElectricSQL’s replication mesh is based on AntidoteDB. Antidote implements the the Cure protocol of transactional causal+ consistency.

The Cure protocol was designed as a “cure for consistency under partitioning” for a synchronization-free, fault-tolerant, highly availabile database. Cure provides causal consistency and highly available transactions. Combined with sticky availability, these create what’s formally proven to be the strongest possible consistency mode for a local-first database system.

Architecture

Antidote is a multi-region, active-active system. ElectricSQL automatically routes replications connections to the nearest region. Each region contains an Antidote cluster. Within the cluster, data is partitioned and sharded across servers with snapshot isolation consistency.

Data is then replicated between regions with transactional causal+ consistency using asynchronous, operation-based replication. The stack looks like this:

You can learn more about the architecture of AntidoteDB here and you can see ElectricSQL’s Vaxine fork of Antidote here.

Causal consistency

Causal consistency guarantees that if a read or write depends on the effects of a previous write then the causal order between them will be respected. However, if two operations are concurrent and have not seen each other, then it’s fine for them to be applied in any order. It also implies that you read your own writes, as per the Jepsen Consistency diagramme below:

Martin Kleppmann has some great videos on the topic (on causal consistency and on logical time) and you can read the original “don’t settle for eventual” paper introducing causal+ consistency here.

CRDTs

ElectricSQL provides conflict-free replication using Conflict-free replicatable data types (CRDTs). In fact, CRDTs were co-invented by two of our advisors, Marc Shapiro and Nuno Preguiça.

CRDTs are data types that can merge concurrent writes without conflicts. They allow clusters to accept writes without cross-region synchronization / replication consensus. Instead, writes can be accepted with low latency and replicated asynchronously, with commutative merge operations ensuring that all clusters converge on strong eventual consistency.

You can see the data types supported by Antidote here, the antidote_crdt repo and this CRDT visualizer.

Rich-CRDTs

ElectricSQL extends Antidote with rich-CRDTs for additional invariant safety. These are CRDTs that:

1. extend and compose the replication semantics of basic CRDTs; and
2. in some cases introduce additional communication protocols in order to preserve invariants

See this post introducing rich-CRDTs.

Highly available transactions

Highly available transactions guarantee the atomic application of a set of operations. I.e: you can wrap multiple writes within a transaction and those writes will either all be applied or none will be applied. See the paper for more information about the guarantees available under high availability and sticky availability.

Sticky availability

High availability allows writes to be accepted at every server, wherever it is in the world. Sticky availability is a mode of high availability where clients always talk to the same server. When this condition is true, it allows high-availability systems to provide additional consistency guarantees, including read-your-own-writes and causal consistency.

TCC+

All of the above properties – CRDTs, causal consistency, highly available transactions and sticky availability – combine in the Cure protocol to provide transactional causal+ consistency, or TCC+.