Strong consistency vs eventual consistency

Welcome! I'm excited to help you master the crucial trade-offs between strong and eventual consistency, a fundamental pillar of designing reliable systems.

To make sure we tailor this session perfectly to your goals, are you preparing for a system design interview, building a specific project, or just looking to understand the concepts generally?

I'm preparing for a system design interview

It's great that you're gearing up for a system design interview. This topic is one of the absolute favorites of interviewers because it forces you to weigh real-world trade-offs rather than just reciting textbook definitions.

To kick things off, let's look at the broad game plan we'll follow to make sure you can confidently architect and defend your consistency choices under pressure.

Your path

How Strong Consistency Works

How Eventual Consistency Works

Real-World System Use Cases

The Core Battleground: Instant vs. Eventually

In a distributed system, your data is cloned across multiple physical servers (replicas) to keep things fast and prevent data loss if a machine dies. But replication introduces a massive dilemma: when a write occurs, how quickly do the other replicas need to know about it?

replication

noun

The process of storing copies of data on multiple physical nodes to ensure high availability and fault tolerance.

Let's break this down using two extreme approaches: 1. : This is the strict approach. If you update your profile picture, the system locks things down and refuses to acknowledge success until every single replica confirms it has saved the new picture. Anyone who reads from anywhere in the world at that exact split-second is guaranteed to see the brand-new picture. 2. : This is the relaxed approach. When you update your picture, the system saves it to the closest replica, immediately tells you "Success!", and then propagates the update to other replicas in the background. For a brief window, a friend in Tokyo reading from a local replica might still see your old picture, but eventually, all replicas catch up and show the new one.

To make this incredibly concrete for your interview, think of a physical analogy.

Imagine a chain of brick-and-mortar clothing stores.

If they use a Strongly Consistent inventory system, a cashier in Chicago cannot sell a jacket until they call the New York, London, and Tokyo stores to lock that item, ensuring every store's ledger is identical in real-time. It's totally accurate, but checkout lines will be painfully slow.

If they use an Eventually Consistent system, each store sells jackets instantly and updates its local ledger. At the end of the day, all stores mail their ledgers to headquarters to reconcile. Checkout is lightning-fast, but occasionally two stores might sell the "last" jacket simultaneously.

In a system design interview, your ability to map these concepts to real trade-offs is what gets you hired. Would you like to see how this dilemma shapes the famous CAP Theorem?