Consistency vs Availability, In Practice
mediumConcept probeVery commonly asked~10 minHLD roundBar raiserPhone screenSDE-2 and upAmazonGoogleMicrosoftAtlassianRazorpayConsistency & Consensus
The question, as asked
“You said the system is eventually consistent. What does that actually mean for a user, and when would you not accept it?”
Scope it before you design it
The prompt is vague on purpose. These are the clarifying questions a strong candidate asks first — answer them out loud before you touch the architecture.
- Ask which operation they mean. 'Is the system consistent' is unanswerable — consistency is a property of a specific read, and different reads in the same system can have different guarantees.
- Clarify whether they're asking about replication lag in normal operation or behaviour during a network partition. These are different questions and CAP only addresses the second.
- Find out what the data is. Stale by a second is fine for a like count and unacceptable for an account balance — the answer is domain-dependent, not architectural.
- Ask who observes the staleness. A user reading their own write is the case people actually notice; a third party reading slightly stale data rarely is.
- Establish whether writes conflict. If two clients can write the same key concurrently, you need a conflict resolution story, not just a consistency label.
- Check whether they want the theory or the practice. Some interviewers want CAP stated correctly; most want to know whether you'd accept stale data here, and why.
Your answer, first
Commit something before anything unlocks. Saved on this device as you go.
0 charactersExpand for room to draw
Framework hint
Sketch or write your approach above first. The hint gives you the structure, not the answer.