Cloud-Optional Design

the realtime end user transactional data generated by your app can be disseminated across devices through three different methods centralized — a small peer device establishes a direct internet enabled connection to the big peer cloud deployment decentralized — a small peer device establishes a mesh network connection with nearby small peer devices using any and all communication transport types available to them by default hybrid — if one or multiple small peer devices connected in the mesh network gain access to the internet, not only do those devices with internet access upload their local ditto store to the big peer cloud, but every nearby offline small peer device as well 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 /#design tradeoffs /#consistency considerations design tradeoffs in distributed systems, 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 consistency considerations 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 type description eventual consistency enforced by small peers, all updates propagate across distributed replicas (local ditto stores) as a single meaningful value, eventually causal consistency enforced by the big peer, data updates are available in real time, without delay comparing consistency models 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 eventually consistent and conflict free 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 strong causal consistency 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 first, you add a new item to the menu, and then you create an order that points to your new menu item when partitioned and replicated across the distributed database nodes, these two independent actions merge in a different order as a result, some peers are unable to observe the new menu item referenced in the order 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