Consistency Models and the CAP Trade-off
A replicated store can behave as though there were one copy, or it can keep serving both sides of a network split and reconcile later. It cannot do both during a partition, and the choice belongs to the application rather than to the database.
What a learner can do afterwards
- Say what a client can observe under strong consistency and under eventual consistency
- Work out what each side of a partitioned system may do under each choice
- Choose a consistency model for a stated application and defend the choice
1 · Read
You already know majorities agree on one value and isolation levels permit chosen anomalies. Consistency is the same idea for replicas. Strong consistency behaves as though there were one copy: every reader sees the latest write. Eventual consistency lets copies disagree for a while and reconciles them later.
A network split divides the store in two. Under strong consistency one side stops answering writes so no split brain grows. Under eventual consistency both sides keep serving and merge their changes when the link heals.
During a partition you cannot have both, and the choice belongs to the application. A bank balance needs strong consistency because spent money must not reappear. A shopping basket can be eventual because merging two baskets later annoys nobody much.
Decide per feature, not per database. Ask what a wrong-then-fixed answer costs your users, and give each feature the weakest model it survives.
Strong behaves like one copy, eventual keeps serving and merges later, and each feature deserves its own choice.
2 · Watch
Take it off screen
Where it sits
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.