Datakonsistens innebär att samma data ser likadan ut överallt. En kunds adress i faktureringssystemet matchar adressen i leveranssystemet. Lagerantalet i lagret matchar antalet på webbplatsen. När systemen inte överensstämmer går besluten fel. Beställningar skickas till gamla adresser. Kunder köper produkter som är slut i lager. Konsistens är inte valfritt för system som är beroende av varandra.

Distribuerade system gör konsekvens svårt. Data som replikeras över flera servrar kan bli osynkroniserade. En nätverkspartition isolerar en region från en annan. Båda regionerna accepterar skrivningar. När partitionen läker uppstår datakollisioner. CAP-teoremet säger att man kan ha konsekvens, tillgänglighet och partitionstolerans, men inte alla tre samtidigt. De flesta distribuerade databaser väljer tillgänglighet och eventuell konsekvens. Det betyder att data konvergerar över tid, men det finns ett fönster där olika noder ser olika värden. Stark konsekvens kräver samordning, vilket kostar latens. Valet beror på applikationen. En bankreskontra behöver stark konsekvens. Ett flöde för sociala medier kan tolerera eventuell konsekvens. Det rätta svaret är inte universellt. Det beror på vad som går sönder när data inte överensstämmer.

Konsistensmodeller

• Stark — alla noder ser samma data omedelbart
• Eventuellt — noder konvergerar över tid
• Kausala — relaterade operationer ses i ordning
• Läs-dina-skrivna-texter — du ser dina egna uppdateringar direkt

Konsekvens är ett spektrum. Frågan är hur mycket inkonsekvens applikationen kan tolerera innan den går sönder.