Consistency

When data lives on several machines, the copies can disagree for a moment. Consistency is about what a read is allowed to see.

Strong and eventual

With strong consistency, every read sees the latest write, no matter which copy answers. With eventual consistency, a read may see old data for a short time. If writes stop, all copies catch up and agree. Strong is easier to reason about but slower, because copies must agree before answering.

CAP in plain words

Sometimes the network between machines breaks, so they can't talk. This is a partition. During a partition, a system must choose:

• Answer anyway, maybe with old data (stay available).
• Refuse until it can be sure the data is the latest (stay consistent).

It can't do both. When the network is fine, it can give both.

Read your own writes

A softer promise: a user always sees their own changes right away. Other users may see them a bit later. One way: for a short time after a user writes, send that user's reads to the copy that took the write.

Quorums

Keep N copies. A write waits until W copies have it. A read asks R copies and keeps the newest value. If W + R > N, the copies read and the copies written always overlap, so a read sees the latest write. With N = 3, W = 2, R = 2, we get 4 > 3, and one machine can be down.

Picking per feature

Choose per feature, not for the whole app. Use strong consistency where old data does real harm, like a bank balance or the last seat on a flight. Use eventual consistency where a short delay is fine, like a like count.

Remember

• Eventual means the copies agree later, not never.
• During a partition: answer with maybe old data, or refuse.
• W + R > N means reads and writes overlap.
• Pick strong or eventual per feature.