"Верить нельзя проверить". Где поставить запятую в асинхронной системе?

Пользователь открывает карточку сотрудника. API отвечает за 80 миллисекунд, Kafka lag в норме, consumer работает, Redis доступен. Но часть данных уже устарела: сотрудник уволен, а один из пользовательских сценариев всё ещё видит его активным.

Как понять, можно ли вообще доверять такому ответу?

Разберём систему, где данные о миллионах людей собираются из нескольких источников и проходят через:

PostgreSQL → Outbox/CDC → Kafka → Read Model → Redis → API

Покажу, почему timestamps, трейсы, Data Lineage и consumer lag хорошо объясняют, что произошло с данными, но ещё не отвечают на вопрос, насколько сильно мы можем доказать их актуальность в момент принятия бизнес-решения.

Сравним несколько способов проверки:

• полную реконсиляцию источника и проекции
• watermarks, чекпоинты, sampling и синтетичесие пробы
• индивидуальное доказательство прохождения значимых изменений
• токен консистентности и version-aware чтения
• authoritative/strong чтения для критических операций.

Главный конфликт: - полная проверка всего потока слишком дорога, - статистическая проверка не гарантирует конкретную запись, - строгая согласованность уничтожает часть преимуществ асинхронной архитектуры.

Поэтому для разных сценариев будем использовать разные гарантии. Информационный профиль может жить с ограниченной eventual consistency. Пользователь после собственной правки должен получить read-your-writes. А критическая операция должна либо получить достаточное доказательство актуальности нужных ей данных, либо честно признать состояние неизвестным и не выполнять действие.

Поговорим о том, где провести границу между точным доказательством и статистической достоверностью, сколько стоит такая доказательность под высокой нагрузкой и почему иногда правильнее вернуть PENDING или отказ, чем быстрый 200 OK с данными, актуальность которых система подтвердить не может.