Priya posts "Is the deploy done?" in the #launch channel of your team chat app. Her phone shows the message as sent. Marco, two desks away, refreshes #launch and sees nothing. Nothing crashed. The message sits on one copy of the data, and Marco's read went to another copy that hasn't received it yet. A consistency model is the rule that says whether that read was allowed, and every design with replicas or caches has one, chosen on purpose or not.

In interviews this rarely arrives as its own question. It arrives as a follow-up inside a replicated design, like "is this strongly or eventually consistent?", and an adjective only earns "strong how?" Expect three to eight minutes of it across a round. Mid-level candidates separate strong, causal, and eventual consistency and name the per-user guarantees behind common bug reports. Senior candidates separate linearizable from sequential and explain why causal order can't be read off a clock. Staff candidates assign different models to different data and say what each costs.

The chat app's channels, replies, reactions, and unique @handles show what each model allows a reader to see. From those outcomes, you can choose the weakest model that still meets each product requirement.

The trade-off is between what a read is guaranteed to see and how long it may have to wait. A stronger model rules out more stale or out-of-order results by waiting for other copies. A weaker model can answer from a nearby copy that has not caught up.

This matters when a read can reach a different copy from the one that handled the write, as with read replicas, multi-region stores, caches, and offline-first clients. With a single database node and no cache in front of it, this replica-consistency choice does not arise. Concurrent transactions on that node raise a different question: isolation.