#eventual_consistency — Public Fediverse posts

Как тестировать распределенные системы: тайм-ауты, дубликаты, Saga и частичные отказы

Распределенная система может сломаться так, что по отдельности все ее части будут выглядеть исправными. Представим обычную оплату заказа: сервис отправил запрос платежному провайдеру, тот списал деньги и вернул успешный ответ. На обратном пути соединение оборвалось. Для платежной системы операция завершена, а сервис заказа получил тайм-аут и не знает, произошло списание или нет. Самое очевидное решение — повторить запрос. И получить второе списание. В монолите подобные ситуации встречаются реже: операция обычно проходит внутри одного процесса или одной транзакции, поэтому место сбоя проще определить. В распределенной системе между началом и концом одной бизнес-операции могут быть несколько сервисов, брокер сообщений, разные базы данных и внешний API (интерфейс программирования приложений). У каждого компонента при этом свое состояние и свое представление о том, что уже произошло. Так, проверки «отправили запрос — получили ожидаемый ответ» здесь недостаточно. Интереснее проверить, что будет, если ответ задержится или потеряется, запрос придет повторно, события поменяются местами, а один из сервисов восстановится после нескольких минут простоя. В таких ситуациях проявляются ошибки, которые сложно увидеть на happy path (позитивном сценарии). Ниже разберем, как их воспроизводить и что проверять, чтобы отказ одного компонента не превращался в некорректное состояние всей системы. Почему распределенную систему нельзя тестировать как обычное приложение Возьмем простой пример — оплату заказа в интернет-магазине.

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

#распределенные_системы #тестирование #таймауты #идемпотентность #Saga #Circuit_Breaker #Fault_Injection #Chaos_Engineering #eventual_consistency #микросервисы

Почему отправленная MDM-команда ещё не означает выполненную

MDM-команда проходит через очередь, инфраструктуру Apple или Google и агент на устройстве. Поэтому ответ API ещё ничего не говорит о фактическом применении политики. Разбираю модель доставки, которую мы используем в Айтера MDM: desired, delivery и observed state, Outbox, ретраи, идемпотентность и разные транспортные контуры Android Enterprise и Apple MDM.

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

#MDM #Android_Enterprise #iOS #APNs #Android_Management_API #Outbox #eventual_consistency #управление_устройствами

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/

#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 #агрегат #сага