Целостность данных в распределенных системах

Уровень 0 · материалов: 4

В кластер входят документы, описывающие механизмы и паттерны обеспечения согласованности данных и предотвращения их потери в распределенных системах.

Общие признаки: микросервисная архитектура, консистентность данных, паттерны Saga и Outbox, идемпотентность

Группа выше: Распределённые системы и согласованность данных

Материалы

• #15735 — Implementing the Outbox Pattern in Microservices Architecture — Представитель этого кластера

  Паттерн Outbox: как не растерять сообщения в микросервисной архитектуре — Mania_c

  Смысл: The text explains how to prevent data loss in microservices using the Outbox pattern to ensure atomic operations between a database and a message broker, while emphasizing that idempotency is required to handle the resulting 'at-least-once' delivery semantics.

  Lamoda Tech solved data loss in their order processing system by implementing the Outbox pattern to guarantee at-least-once message delivery combined with consumer-side idempotency.

• #24998 — API Idempotency Lessons through Vasya the Intern

  Стажёр Вася и его истории об идемпотентности API — jirfag

  Смысл: The main idea is that any API modifying state in a distributed system must be designed as idempotent to prevent data duplication and inconsistent states caused by network timeouts, retries, and race conditions.

  Using a fictional intern's mistakes, the author explains how to implement API idempotency using idempotency keys and state versioning to prevent duplicate actions in distributed systems.

• #12363 — Implementation of the Saga Pattern in Microservices

  Паттерн: Сага — pavzay

  Смысл: The main idea is to explain the Saga pattern as a solution for maintaining data consistency across multiple microservices without relying on distributed ACID transactions, utilizing either event-driven choreography or centralized orchestration.

  The Saga pattern ensures data consistency in microservices by using a sequence of local transactions with compensating actions for failures, coordinated via choreography or orchestration.

• #22884 — The Pyrrhic Victory of Domain-Driven Design

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

  Смысл: The main idea is that tactical DDD's insistence on small aggregate-based transaction boundaries forces an over-reliance on Sagas, which are too complex to implement reliably, ultimately leading to inevitable data corruption in the database.

  Tactical DDD's use of small aggregate transaction boundaries leads to an unmanageable number of Sagas, which inevitably causes business logic invariants to be violated in the database.