How do you reason about consistency and availability?

Direct answer

What a strong answer covers

How it works

When nodes cannot talk to each other, a write can either be refused until the partition heals, keeping every replica consistent, or accepted on whichever side received it, keeping the service available at the cost of divergent copies that must be reconciled later. The choice is made per operation, not per system: a balance transfer cannot tolerate divergence, a like counter can. Most designs mix both, using a strongly consistent store for invariants that must hold and eventually consistent replication for everything else, and they make read semantics explicit so clients know when they might see stale data.

Example

An inventory system rejects a sale when it cannot reach the primary for that SKU, because overselling costs more than a refused checkout; the same system serves product descriptions from any replica even if they lag by a minute. A collaborative document accepts edits offline and merges them with CRDTs because losing a user’s typing is worse than a brief inconsistency.

Common mistakes

• Applying one consistency choice to the whole system without looking at each invariant.
• Claiming a system is both always consistent and always available under partition.
• Serving stale reads without telling clients that the data may be stale.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.