🎯 Core Consistency Framework
When discussing consistency models, I frame the problem across four dimensions:
- What guarantee the system provides (Strong vs Eventual)
- User experience & correctness requirements
- Failure scenarios & anomalies
- Practical patterns to bridge the gap
1️⃣ Strong vs Eventual Consistency
Strong Consistency
Definition:
- All reads reflect the latest committed write
👉 Interview Answer
Strong consistency guarantees that every read returns the most recent write. I typically use it for systems where correctness is critical, such as payments or inventory. The trade-off is higher latency and reduced availability, because the system needs coordination across replicas before responding.
Eventual Consistency
Definition:
- System converges over time, reads may be stale
👉 Interview Answer
Eventual consistency allows reads to be temporarily stale, but guarantees convergence over time. It’s useful for large-scale systems like feeds or analytics where availability and latency matter more than immediate correctness. The trade-off is handling anomalies like stale reads and conflicting updates.
Summary Insight
Strong consistency simplifies reasoning but limits scalability. Eventual consistency scales well but pushes complexity into the application layer.
2️⃣ What Actually Matters: User Semantics
Key Insight
Consistency is a user experience guarantee, not just a storage property.
Practical Consistency Choices
Read-your-writes
👉 Interview Answer
For user-facing updates like profile edits, I usually ensure read-your-writes consistency. This can be implemented by routing reads to the leader or using session stickiness, so users immediately see their own updates.
Monotonic Reads
👉 Interview Answer
Monotonic reads ensure that once a user sees a value, they won’t see an older version later. This is important for timelines or dashboards to avoid confusing regressions in data.
Session Consistency
👉 Interview Answer
Session consistency provides guarantees within a user session. It’s a practical middle ground where we don’t enforce global strong consistency, but still provide a consistent experience per user.
Key Takeaway
We don’t choose consistency globally — we tailor it per user interaction.
3️⃣ Failure Scenarios & Anomalies
Scenario 1: Read-after-write inconsistency
👉 Interview Answer
A common issue is when a user writes data and immediately reads stale data from a replica. I typically solve this by routing reads to the leader or using session stickiness. Another approach is versioning, where the client ensures it only accepts newer data.
Scenario 2: Write conflicts
👉 Interview Answer
In eventually consistent systems, concurrent writes can conflict. A simple approach is last-write-wins, but for critical data, I would use versioning or conflict resolution strategies like CRDTs to ensure correctness.
Scenario 3: Stale aggregates
👉 Interview Answer
Aggregated data like counts may be stale due to asynchronous updates. I usually accept eventual consistency here and rely on background reconciliation or approximate counters to balance performance and accuracy.
Scenario 4: Network partition
👉 Interview Answer
During a network partition, we must choose between consistency and availability. Strongly consistent systems may reject writes, while eventually consistent systems continue operating but may diverge. The choice depends on whether correctness or availability is more critical.
4️⃣ Practical Design Patterns
Pattern 1: Leader-based reads
👉 Interview Answer
For critical operations, I route both reads and writes to the leader to ensure strong consistency. For non-critical reads, I use replicas to improve scalability.
Pattern 2: Versioning & reconciliation
👉 Interview Answer
I often attach version numbers or timestamps to data. This allows the system to detect stale reads and resolve conflicts during reconciliation.
Pattern 3: Event-driven consistency
👉 Interview Answer
Many systems use asynchronous pipelines to propagate updates. This enables high scalability, but requires handling eventual consistency and retries.
Pattern 4: Bounded staleness
👉 Interview Answer
Instead of strict consistency, I sometimes guarantee that data is at most a few seconds stale. This provides a predictable user experience while maintaining performance.
🧠 Staff-Level Answer (Polished)
When discussing consistency, I map it to user-facing guarantees rather than treating it as a binary choice. Strong consistency ensures correctness but comes with latency and availability trade-offs, while eventual consistency improves scalability but introduces anomalies.
In practice, I choose consistency per use case. For example, payments require strong consistency, while feeds can tolerate eventual consistency.
I also account for failure scenarios like replica lag and network partitions, and mitigate them using techniques such as leader reads, session stickiness, and versioning.
Most production systems use hybrid approaches to balance correctness, performance, and user experience.
⭐ Staff-Level Insight
The goal is not to eliminate inconsistency — it’s to control where it appears and make it acceptable to users.
中文部分
每部分面试一句话总结
Strong
强一致保证永远读到最新数据，但延迟高、可用性低
Eventual
最终一致允许短暂不一致，但换来高可用和高性能
用户视角
一致性本质是用户体验问题，而不是数据库问题
故障处理
关键是处理读旧数据、写冲突、网络分区
设计策略
实际系统采用混合一致性：关键路径强一致，非关键路径最终一致
Implement