Фронтенд-счетчик показывает 10k успешных оплат, а бэкенд-таблица заказов — 8k за тот же день. Какой следующий шаг в reconciliation наиболее полезен?
AСразу решить, что фронтенд всегда прав, и игнорировать бэкенд
BСразу решить, что бэкенд всегда прав, и игнорировать фронтенд
CВзять среднее между 10k и 8k, чтобы получить компромиссное число
DСопоставить записи по
order_id и разложить расхождение по стадиям request, payment, callback, finalizeПравильный ответ.
reconciliation лучше всего делать на уровне идентификаторов и этапов процесса, а не сравнивать только агрегаты.Разбор
Сопоставление по order_id показывает, какие заказы видны на фронте, но не дошли до финализации на бэкенде, и наоборот. Разложение по стадиям выявляет, где именно теряются события: в logging, в очереди, в обработчике или в витрине. Это позволяет быстро отличить проблему данных от реального сбоя бизнес-процесса оплаты.
Проверь себя · 1/3разбор после ответа
Выручка по событиям в продуктовой витрине на 5 процентов выше, чем в платежной системе за тот же день. Что логичнее всего проверить первым в рамках
reconciliation?Ещё вопросы по теме «Качество данных и инварианты»
- В ежедневном дашборде `DAU` и количество событий резко упали начиная с 02:00 и остаются низкими до конца дня. Что проверить первым, чтобы быстро понять, это `missing data` или реальный бизнес-эффект?
- Какой `invariant` наиболее уместно добавить в ежедневный отчет по воронке e-commerce, чтобы ловить ошибки данных?
- Выручка по событиям в продуктовой витрине на 5 процентов выше, чем в платежной системе за тот же день. Что логичнее всего проверить первым в рамках `reconciliation`?
- Вчера число событий `purchase` выросло в 2 раза, но число уникальных `order_id` почти не изменилось. Какой источник проблемы наиболее вероятен?
- Метрики за понедельник резко просели, а за вторник резко выросли, при этом сумма за 2 дня почти не изменилась. Какой `sanity check` лучше всего указывает на `time shift`?
- Все вопросы по «Качество данных и инварианты» →