Eventual Consistency: как мы починили тормоза апрува и сломали бюджет

Мы убрали одну блокировку, чтобы апрувы перестали тормозить. Через несколько недель из-за этого клиент пробил квартальный бюджет – а наша система этого даже не заметила. B2B travel SaaS, конец 2016-го. Два руководителя финансового департамента одновременно открыли форму апрува, оба увидели один и тот же остаток, и каждый одобрил поездку, которая по отдельности в бюджет вписывалась. Вместе они пробили лимит. Узнали мы об этом из звонка клиента, не из алерта. Дальше – три вопроса про eventual consistency, которые стоит задать до архитектуры, а не на разборе инцидента.

https://habr.com/ru/articles/1042256/

#eventual_consistency #согласованность_данных #CQRS #оптимистичная_блокировка #EF_Core #проекции #saga #идемпотентность #распределённые_системы #read_model

Eventually-consistent СУБД — всё?

В начале 2010-х в профессиональном сообществе разработчиков и архитекторов распределенных систем широко обсуждалась идея, что мир баз данных вступает в новую эру. На фоне успехов крупных интернет-сервисов термин BASE начал использоваться как противопоставление классическому ACID. Хайп вокруг NoSQL, CAP-теоремы и масштабируемых систем породил лозунги вроде «SQL умер», «ACID — для банков, а мы делаем веб», «eventual consistency — это нормально». Однако спустя полтора десятилетия крупные облачные и корпоративные платформы по-прежнему говорят языком транзакций, изолированных операций и строгой согласованности. Что же произошло? Была ли «битва ACID и BASE» реальным технологическим разломом или лишь отражала ограничения своего времени? В этой статье мы разберём, как возникли ACID и BASE, почему BASE быстро стал популярен и что на самом деле означает тезис «победил ACID» в 2020-е годы.

https://habr.com/ru/articles/980082/?utm_source=habrahabr&utm_medium=rss&utm_campaign=980082

#acid #base #eventual_consistency #субд #базы_данных #распределенные_системы

Eventually-consistent СУБД — всё?

В начале 2010-х в профессиональном сообществе разработчиков и архитекторов распределенных систем широко обсуждалась идея, что мир баз данных вступает в новую эру. На фоне успехов крупных интернет-сервисов термин BASE начал использоваться как противопоставление классическому ACID. Хайп вокруг NoSQL, CAP-теоремы и масштабируемых систем породил лозунги вроде «SQL умер», «ACID — для банков, а мы делаем веб», «eventual consistency — это нормально». Однако спустя полтора десятилетия крупные облачные и корпоративные платформы по-прежнему говорят языком транзакций, изолированных операций и строгой согласованности. Что же произошло? Была ли «битва ACID и BASE» реальным технологическим разломом или лишь отражала ограничения своего времени? В этой статье мы разберём, как возникли ACID и BASE, почему BASE быстро стал популярен и что на самом деле означает тезис «победил ACID» в 2020-е годы.

https://habr.com/ru/articles/980082/

#acid #base #eventual_consistency #субд #базы_данных #распределенные_системы

Пиррова победа Domain-Driven Design

TL;DR: DDD неизбежно ведёт к избыточному (на порядки больше минимально необходимого) количеству саг в проекте, которые, в свою очередь, неизбежно ведут к нарушению целостности данных в БД. DDD вполне успешно решает поставленную задачу: дать разработчикам инструменты, которые позволят им справится (корректно реализовать и поддерживать) со сложной предметной областью. Но эта победа оказалась пирровой: инструменты, обеспечивающие корректность данных в памяти , оказались неспособны гарантировать корректность данных в БД . А что толку от изначально корректных данных в памяти, если со временем (после их сохранения в БД и последующего чтения) они перестают быть корректными? По сути, у DDD есть фатальный недостаток: DDD неизбежно приводит к нарушению целостности данных (инварианта бизнес-логики) в БД .

https://habr.com/ru/articles/800385/

#DDD #DomainDriven_Design #eventual_consistency #aggregate #saga #агрегат #сага