Перейти к содержанию

Ordering, sequencing и out-of-order events

Раздел 04 · Типы достоверности

Тип материала: инженерный разбор. Схемы и примеры иллюстративные. Рекомендации — INFERENCE; учебные параметры — HYPOTHETICAL.

Проверка источников: 2026-11-02. Версии и границы первоисточников перечислены в конце. Documented contracts не означают выполненный runtime test.

Принцип работы и границы

Порядок transport, event time и бизнес-ревизий различается. Partition log задаёт последовательность записей одной partition; event timestamp не является доказательством causal order. Несколько producers, повтор публикации и parallel workers могут изменить порядок effects даже при правильном порядке чтения.

Для state entity используйте owner-assigned revision и contract: latest-state upsert может принять revision выше текущей, а delta chain часто требует следующую непрерывную revision. Нельзя пропустить debit delta только потому, что уже встретилась следующая revision. Для одинакового key+revision payload должен быть идентичен; иначе quarantine.

FACT: Kafka ordering относится к partition. Design 4.1. INFERENCE: stable partitioning key, serial application per entity и guarded state transitions нужны дополнительно. Изменение partition count может изменить маршрутизацию key; migration требует drain/cutover, а не надежды на прежний порядок.

Иллюстративная архитектура

flowchart LR
 K[Partition log] --> W[Per-key sequencer]
 W --> G{Revision contract}
 G -->|expected| D[Guarded apply]
 G -->|gap| B[Bounded gap buffer]
 G -->|old or duplicate| I[Identity and payload check]

Failure scenarios

Revision 3 приходит до 2; buffer переполняется либо revision 2 уже потеряна. Parallel task для offset 12 завершает DB commit раньше 11. Клиент прислал одинаковую revision с другим amount. Старый producer продолжает писать во время repartition migration.

Recovery protocol

  1. Определить entity-specific order contract: snapshot state либо chain deltas.
  2. Сохранить gap evidence, остановить зависимые effects и запросить пропущенные события из authoritative history.
  3. Восстановить непрерывную цепочку либо явно заменить состояние certified snapshot с watermark.
  4. Отвергнуть stale/conflicting writes по revision и payload fingerprint.
  5. Проверить invariants, затем продвигать contiguous processing frontier.

Trade-offs и критерии выбора

Буфер late events требует памяти/диска и bounded waiting policy. Drop stale допустим для last-known display, но опасен для additive postings. Total order всех событий упрощает reasoning ценой throughput и availability; per-entity order обычно достаточен.

FinTech и iGaming

Bet accepted→settled→re-settled нуждается в domain revision, а сумма reversals — в identity исходной проводки. Wallet balance нельзя вычислять по max timestamp. При corrections аналитика должна ретрактить старый вклад, а не суммировать обе версии.

Практический пример

HYPOTHETICAL: доставки r1=accepted, r3=corrected, r2=settled, повтор r3. Для state projection итог r3; для финансовых deltas сначала требуется восстановить r2 и проверить compensating operations. Пройдите rebalance scenario и найдите место, где serial log становится parallel effects.

Типичные ошибки проектирования

Использовать wall clock как sequence; сортировать только пришедший batch; коммитить max completed offset через gap; replay каждой revision как нового полного вклада.

Вопросы на собеседовании

Решает ли watermark финансовый порядок? Нет: это progress estimate для event-time обработки, не доказательство наличия каждой domain revision.

Можно ли игнорировать старую revision? Для полного state snapshot иногда да; для delta ledger требуется identity и полнота цепочки.

Дополнительные источники