11.4.2: Consistency Models

Here are some common models, from strongest to weakest:

• Strong Consistency (Linearizability): After an update is committed, any read on any replica will see that update (as if there is a single up-to-date copy at all times). This is akin to the system behaving like a single database – operations appear in a global order. In practical terms, strong consistency means if you do a write and then immediately read (from any node), you will get the value you wrote (also called read-your-write guarantee, and generally any read reflects the most recent completed write). Cloud Spanner provides this – “every read reflects the most recent updates, regardless of the size or distribution of your data". Achieving this often requires techniques like distributed locking or consensus on writes [2]. Strong consistency simplifies reasoning for developers (no stale data concerns) but, per the CAP theorem, requires sacrificing availability if partitions occur.
• Sequential Consistency: A slightly weaker model than linearizability – it ensures all nodes see operations in the same order, but not necessarily tied to real-time order. This means the system’s operations can be ordered in some sequence that is consistent across all observers, though if one client’s writes might appear instant to itself but others might see them later out of wall-clock order. (Linearizability is sequential consistency + real-time order guarantee). This model is more theoretical; many systems aim for linearizability or the next one, causal.
• Causal Consistency: If one operation happens before another (for example, client A updates a value, then communicates to client B that it did so), then everyone must see A’s update before B’s subsequent update. Causal consistency respects the causality of operations but unrelated operations might be seen in different orders on different nodes. Achieving causal consistency often involves tracking dependency metadata (like vector clocks). It’s stronger than eventual consistency but not as strict as linearizable.
• Eventual Consistency: This is a very common weak model used by many AP-oriented distributed systems (like Dynamo style). It guarantees that if no new updates are made, eventually all replicas will converge to the same value. However, there’s no guarantee when a given read will reflect a recent write. In an eventually consistent system, after you perform a write, a subsequent read might get the old value if it hits a replica that hasn’t gotten the update yet. Over time (usually seconds or less), the replicas sync up. DNS on the internet is a classic eventually consistent system (updates propagate after some time-to-live). Eventual consistency maximizes availability and partition tolerance, as writes can always be accepted somewhere and users can read from any replica. But it forces the application to handle anomalies like reading stale data or even read-your-writes violation (you post a comment and refresh, but still see the old state because you hit a different replica).

The CAP Theorem famously states that in the presence of a network Partition, a distributed system must choose between Consistency and Availability [4]. In practice, designers choose a balance. For instance, MongoDB and Redis (often run in single-primary mode) prioritize consistency over availability (they’ll failover rather than allow conflicting writes) – they’d be categorized as CP (Consistent, Partition-tolerant) in CAP terms. On the other hand, Cassandra or DynamoDB (by default) prioritize availability – they’ll accept writes during partitions and reconcile later (AP: Available, Partition-tolerant, eventually consistent). There are practically no distributed systems that are CA (Consistent and Available with no partition tolerance), because network partitions can always happen; CA would mean not distributed or sacrificing partition tolerance, which is generally unrealistic. Instead, when no partition is happening (which is most of the time), a well-designed system can have both consistency and availability – CAP really matters during failures.

Tunable consistency: Many cloud databases allow adjusting the consistency per request or database: for example, Azure Cosmos DB offers five consistency levels: Strong, Bounded Staleness, Session, Consistent Prefix, and Eventual, letting you trade-off consistency vs latency. Session consistency (a commonly used default in Cosmos) guarantees read-your-writes and monotonic reads for a single session (client) – which is often enough for a good user experience, while still replicating async globally for performance. DynamoDB’s API allows the choice of strongly consistent read (reads from leader, ensuring up-to-date) or eventual (reads from local replica, faster). This flexibility shows that consistency isn’t one-size-fits-all; different parts of an application may need different guarantees.

Real-world scenario: Consider a globally distributed shopping cart service. If it uses eventual consistency, a user who adds an item to their cart might not see it immediately on a page reload if the read went to a replica that hasn’t gotten the update – but eventually it will appear. If strong consistency is used, every add-to-cart will be immediately visible on subsequent reads (at the cost of possibly higher latency if it must confirm across continents). Many systems compromise by giving users read-after-write consistency for their own actions (often implemented via session consistency or by directing a user’s reads to the same replica that handled their write). This satisfies user expectations most of the time without making the entire system strongly consistent for all users (which would be slower).

Case study – banking vs social media: In banking, consistency is crucial (you don’t want to withdraw money based on a stale balance). Banking systems often opt for CP: if the network is partitioned, they’d rather block some operations than allow inconsistent updates. ATMs historically allow overdrafts partly due to replication delays (an example where availability was slightly prioritized – as IBM Cloudant’s docs note [4], “inconsistent banking data is why it’s still possible to overdraft money… it’s unrealistic to present a consistent view… if every node must halt and record this figure”). For a social media feed, availability is more important – the site should stay up and show you something, even if a few likes or comments are missing for a minute. Users prefer an eventually-consistent but highly available service to one that’s perfectly consistent but occasionally offline.

In cloud project management, one must decide the appropriate consistency model for each component. Often this means using strong consistency for critical data (financial info, inventory counts, etc.) and eventual or weak consistency for less critical or high-throughput data (analytics, logs, cached views). Modern databases and caches allow these trade-offs, and the CAP theorem serves as a reminder that you can’t maximize everything simultaneously – you design for the trade-off. For example, DynamoDB chose availability+partition tolerance, and deals with conflicts via a “last write wins” strategy (clients may occasionally see stale data, but the system never goes down due to a partition). Spanner chooses consistency+partition tolerance (it will never return stale data, but if a partition to a region occurs, that region might be unable to accept writes until it rejoins) – Google mitigates this with their private network and TrueTime to make partitions rare and short [2].

To connect back to replication strategies: a primary-secondary system typically gives strong consistency for writes (to primary) and if reads are from primary or sync replicas, overall strong consistency. An async replication system gives eventual consistency on secondaries. A multi-master like CouchDB is eventually consistent unless you do extra conflict handling. Quorum systems can give tunable consistency depending on R, W settings. It’s crucial to also implement conflict resolution for eventual consistency: e.g., if two users edit the same wiki page offline, when both changes sync, the system must merge them or pick a winner.

In conclusion, consistency models determine the data behavior users experience in a distributed cloud application. Strong consistency simplifies the mental model (like dealing with a single up-to-date database) but can reduce system availability or performance. Eventual consistency maximizes robustness and performance but requires thinking about stale or conflicting data. Many cloud systems aim for a balance – for instance, guaranteeing “read-your-own-write” consistency and monotonic reads (you won’t go backwards in time) which are user-friendly properties, even if full global consistency isn’t provided. As a cloud project manager or architect, being explicit about these guarantees in the design is important so that developers know what to expect and users get a satisfactory experience.