Каждое звено обещает своё, а отвечать приходится за цепочку целиком: как at-least-once складывается в effectively-once, где заканчивается транзакция Kafka, почему дедуп на стоке обязателен и как пайплайн переживает replay, эволюцию схемы и битые события
Стрим-процессор без надёжного состояния бесполезен: агрегаты, джойны, дедуп — всё это состояние, которое нельзя потерять при падении. Как Flink это решает: keyed vs operator state, state backends (heap vs RocksDB для состояния больше памяти), распределённые снапшоты через барьеры (алгоритм Chandy-Lamport), инкрементальные checkpoints и savepoints для апгрейда, и exactly-once end-to-end через two-phase commit в стоки
Как Kafka даёт exactly-once: идемпотентный producer, транзакции с transactional.id, атомарный consume-process-produce через sendOffsetsToTransaction и consumer read_committed — и где граница EOS (внешние сайд-эффекты), которую закрывает outbox
Что значит «транзакция» в брокере: AMQP-транзакции RabbitMQ против publisher confirms, транзакционный producer и exactly-once в Kafka, consume-process-produce и read_committed, границы EOS и outbox-паттерн как мост к БД. Примеры на Go и Java
Вся событийная архитектура держится на одной связке, которую редко проговаривают вслух: at-least-once доставка + идемпотентный консьюмер = effectively-once. Разбираем, почему сквозной exactly-once недостижим в принципе, чем at-least-once отличается от at-most-once, как сделать консьюмер идемпотентным (ключи идемпотентности, dedup-хранилище, естественная идемпотентность, окно дедупа) и где эта связка уже работает в серии — в outbox, saga и проекциях
