As a cloud-optional data management platform, you get to choose the distributed system architecture that best meets your unique goals and use cases.

In this topic, you'll learn about the three characteristics of distributed systems and how Ditto offers a flexible data experience by blending the best qualities of the transactional edge (Small Peers) and analytical cloud (Big Peer) in a single distributed system architecture:

In distributed system design, in which a network stores data on more than one node, it is impossible to guarantee that all CAP theorem fields — consistency, availability, and partition tolerance — are met. In plain language, you can’t have it all when designing a decentralized distributed system architecture.

In addition, when contending with asynchronous communications, in which unstable network conditions may cause data delays, reordering, or loss, guaranteeing partition tolerance is a must. Therefore, you must choose to sacrifice high availability or strong consistency in your architecture model.

Also referred to as Brewer's Theorem, the following graphic illustrates this CAP theorem logic:

Within Ditto's underlying infrastructure are the following two distinct consistency models that work in tandem to achieve reliable data management. A consistency model establishes guarantees regarding the order and visibility of updates across the system.

The following table provides an overview of the two types of consistency models Ditto provides:

When compared to the Small Peer eventually consistent model, the Big Peer causal consistency model is considered to be much more straightforward to implement in terms of ease.

This is due to the causal consistency model’s relaxed approach to immediate consistency guarantees, which are susceptible to concurrency conflict.

SmallPeers enforce strong eventual consistency by way of conflict-free replicated data types (CRDTs) technology.

As the foundation of how Ditto exposes and models data, CRDTs ensure that any data inconsistencies that occur as a result of concurrency conflicts eventually merge into a single value. A concurrency conflict is a simultaneous update made to the same data items stored in different database replicas.

Ditto’s CRDTs are state-based, which means that only the data that has changed, known as the delta, replicates across peers in the mesh network. This paradigm ensures highly frequent and efficient peer-to-peer data transmission. 

With the principles of eventual consistency, it seems like anything is allowed to happen: if two actions are totally unrelated, they can be ordered any way the system chooses.

This is the opposite of the causally consistent model, which, as the name implies, entails that if one action occurs before another and therefore influences that other action, the two actions must be ordered in that exact same sequence for every execution.

As an example, imagine that you have two collections: Menus and Orders:

Causal consistency ensures that the menu item is added before the order is created, regardless of the unpredictability and uncertainty of networks, connections, and ordering of messages.

Transactional causal consistency means that, as long as these independent operations are written to the same Ditto store, you can apply this constraint across any number of related changes, across multiple documents, and in multiple collections.

This model is much simpler to understand than eventual consistency, leading to fewer technical surprises during development, implementation, and operation.