Consistency Models

In a distributed system with multiple replicas, how do we ensure everyone sees the same data? We use Consistency Models to define the contract between the application and the database.

1. Strong Consistency

After a write finishes, every subsequent read will see the updated value. This requires **locking** replicas during the write process, which significantly increases latency and reduces availability.

2. Eventual Consistency

If no new updates are made, eventually all replicas will converge on the same value. In the short term, different users might see different data. Example: Amazon's "Add to Cart"—it doesn't matter if your cart takes 1 second to sync across all servers as long as the state is eventually correct. This allows for massive throughput.

4. Interview Mastery

Q: "What is 'Read Your Own Writes' consistency?"

Architect Answer: "It is a hybrid model. Even in an eventually consistent system, we want a specific user to see the change they just made immediately. We achieve this by ensuring that the **User's Session** is pinned to the specific node they wrote to, or by having the client keep a local copy of the change until the backend replicas have converged. This prevents the 'I just tweeted but my profile doesn't show it' bug."