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

End-to-end processing guarantees

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

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

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

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

Составьте граф durable boundaries: source acceptance, processing state, transport output, sink commit и внешнее действие. Для каждой стрелки нужны identity, retry decision и способ выяснить неизвестный результат. Сильная локальная транзакция не объединяет соседние commits автоматически.

FACT: Flink checkpoints согласуют managed state и позиции replayable sources; гарантии внешнего результата зависят от sink integration. Flink 1.20.3. INFERENCE: документируйте гарантию как «вход X → результат Y при условиях Z», включая crash, retention, failover и доступность identity store.

Сервис списания может принять запрос и потерять ответ. Если внешний API не предоставляет durable idempotency/status lookup, transport retry не способен доказать единственность эффекта. Такое ограничение остаётся UNKNOWN для конкретного API, пока контракт не установлен.

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

flowchart LR
 S[Accepted source identity] --> P[State and checkpoint]
 P --> T[Committed output]
 T --> D[Durable sink effect]
 D --> X[External payment API]
 X -. status by operation ID .-> D

Failure scenarios

Успешный checkpoint с последующим rollback Redis создаёт пробел serving state. DB commit и crash до broker acknowledgement создают повтор. Два корректных по отдельности потока могут публиковать разные версии финансового периода. Потерянный API ACK оставляет статус ambiguous, а не failed.

Recovery protocol

  1. Для каждой границы составить таблицу «durable evidence / отсутствует / неизвестно».
  2. Запретить новые необратимые действия для unresolved operation IDs.
  3. Восстановить источник и state к совместимому cut; sink пересоздать в новой generation либо довести идемпотентно.
  4. Внешний эффект проверить через status API и settlement evidence, не повторять с новым ключом.
  5. Сверить множества IDs и финансовые итоги до публикации recovered generation.

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

Общая распределённая транзакция ограничивает технологии и доступность. Idempotency плюс reconciliation допускает повторные доставки и временную задержку, но требует долгоживущей identity и управления unresolved состояниями. Для отчёта разумнее новая generation; для денежного эффекта — durable command protocol.

FinTech и iGaming

При settlement authoritative ledger, Kafka notification и ClickHouse dashboard имеют разные моменты финальности. UI не должен подтверждать выплату лишь по processing checkpoint. Антифрод может отдавать incomplete feature state, если policy явно обрабатывает этот статус.

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

Заполните failure matrix для Kafka→Flink→Redis и сравните со сценарием C. Для каждой границы приложите log offsets, checkpoint ID и sink generation. Локальная модель не проверяет двухфазный commit sink.

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

Подменять business success HTTP 200 relay; ссылаться на Kafka transactions как на транзакции PostgreSQL; объявлять Redis synchronized только по восстановлению Flink.

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

Как доказать E2E? Определить инвариант, покрыть все durable boundaries и исполнить failure/recovery проверки с независимой сверкой.

Поможет ли повторить запрос к неидемпотентному API? Это может создать второй эффект; сначала нужен протокол разрешения ambiguous outcome.

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