Eventual consistency and strong consistency represent a trade-off between availability/performance and immediate data accuracy in distributed systems.
Key Points: • Eventual consistency allows operations to proceed without waiting for all nodes or services to agree, improving availability and response times. • With eventual consistency, there is a window where different parts of the system may briefly show stale or differing data before converging. • Strong consistency guarantees that all reads reflect the latest write, but requires coordination between nodes, which adds latency and can reduce availability during network issues. • The CAP theorem frames this trade-off: under a network partition, a system must choose between consistency and availability. • The right choice depends on the use case: financial balance updates often need strong consistency, while a product view counter can tolerate eventual consistency.
Example: A social media like-count can use eventual consistency, briefly showing slightly different counts to different users, while a bank transfer needs strong consistency so two withdrawals can't both succeed against the same insufficient balance.
Interview Tip: A concise interview answer is:
"Eventual consistency favors availability and performance by letting operations proceed without immediate agreement across nodes, accepting brief staleness. Strong consistency guarantees every read sees the latest write but costs latency and availability during coordination. I pick based on the use case, strong consistency for money movement, eventual consistency for things like view counts or search indexes."