Что такое Eventual Consistency и как с ней бороться.

Когда процессоры были большими, базы данных - маленькими, а приложения - монолитными (а то и вообще пользовательскими 😉) все активно топили за строгую согласованность. В самом деле, удобно - целостность данных обеспечивается, что один записал - то другой и прочитал, красота, да и только. Тогда придумались транзакции, ACID и прочие премудрости, сводящиеся к тому, что Strong Consistency - это хорошо и правильно.

Однако время шло, процессоры в размерах уменьшались, а базы данных и приложения росли, росли и постепенно перестали помещаться в маленьких процессорах, стали распространяться на несколько узлов и превратились в распределенные. Это было удобно, много маленьких приложений лучше обрабатывали большие потоки данных, чем один большой. Если одно из них сдохнет - никто и не заметит.

Хотел коротко, не получилось, пришлось освоить telegraph.
Продолжение тут https://telegra.ph/CHto-takoe-Eventual-Sonsistency-i-kak-s-nej-borotsya-11-09