최종 일관성 이해하기

Welcome! In distributed systems, keeping data perfectly in sync across many servers is hard. This lesson introduces Eventual Consistency, a common approach for managing data in such environments.

It's a powerful concept that balances data consistency with high availability and performance.

Eventual Consistency means that if no new updates are made to a given data item, eventually all accesses to that item will return the last updated value. In simple terms:

• Data might not be identical across all copies immediately.
• But, given enough time, it will become consistent.

Think of it as eventually catching up.

Why would we choose 'eventual' over 'immediate' consistency?

• High Availability: Services can still respond even if some data copies are temporarily out of sync.
• Scalability: Easier to scale by adding more servers without complex coordination.
• Performance: Updates don't need to wait for all replicas, reducing latency.

It's a trade-off for speed and uptime.

The CAP Theorem states a distributed system can only guarantee two out of three properties: Consistency, Availability, and Partition Tolerance.

• Eventual Consistency often prioritizes Availability and Partition Tolerance.
• This means it sacrifices immediate strong Consistency to ensure the system remains operational and responsive even when parts of it are disconnected.

When data is updated in an eventually consistent system, here's a simplified flow:

1. An update is written to one or more primary nodes.
2. These nodes asynchronously replicate the update to other copies.
3. During this propagation, different users might temporarily see different versions of the data.

This asynchronous nature is key to its benefits.

While 'eventual' means eventual, some systems offer stronger guarantees within that model. One is Read-Your-Writes Consistency:

• If you update data, your subsequent reads will always reflect your own update.
• Other users, however, might still see the older version for a short period.

This provides a better user experience for their own actions.

Another useful consistency guarantee is Monotonic Reads:

• Once you've read a certain version of data, you will never read an older version in subsequent requests.
• This prevents a user from experiencing 'time travel' where data appears to revert to an earlier state.

It ensures a consistent view of data for a single user's session.

Consider a social media platform where you 'like' a post. This is a perfect use case for eventual consistency:

• When you click 'like', your client immediately shows the updated count.
• The update is sent to the server and asynchronously replicated.
• If other users don't see the updated count instantly, it's generally acceptable.

Availability and responsiveness are more critical than immediate global consistency.

For an online shopping cart, eventual consistency can be used, but with care:

• When you add an item, you expect to see it immediately (Read-Your-Writes).
• If multiple users try to update the same cart (e.g., shared cart), conflicts can arise.

Conflict resolution strategies (like 'last write wins' or custom merging) become crucial here.

You've learned about Eventual Consistency!

• It's a model where data eventually becomes consistent.
• It's chosen for high availability, scalability, and performance.
• It's a trade-off, often prioritizing A and P in the CAP Theorem.
• Concepts like Read-Your-Writes and Monotonic Reads offer stronger guarantees within this model.

Next, we'll look at the broader challenges of transaction management in microservices.