Reconciliation и financial correctness¶

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

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

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

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

Reconciliation сопоставляет независимые свидетельства о business operations при одинаковом cut, currency, tenant и правилах коррекции. Проверяются множества keys, cardinality, amounts и balances; совпадение одной общей суммы недостаточно, поскольку две ошибки могут взаимно сократиться.

INFERENCE: expected set должен происходить из authoritative evidence, а не из той же потерявшей данные target таблицы. Привяжите сверку к source snapshot/offset vector и generation, различайте late arrivals и permanent discrepancy. Reconciliation не создаёт само по себе атомарности и не исправляет ошибку автоматически.

Для ledger проверяются балансировка postings по transaction и currency, отсутствие повторного operation_id и соответствие external settlement evidence. PostgreSQL 17 isolation задаёт возможности локального snapshot; согласованный cut двух систем требует отдельного протокола.

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

flowchart LR
 S[Authoritative source cut] --> E[Expected keys and totals]
 T[Target generation] --> A[Actual keys and totals]
 E --> C[Compare by tenant and currency]
 A --> C
 C --> X[Exception workflow and corrections]

Failure scenarios¶

Missing debit и missing credit дают равную общую сумму при неверных счетах. Target и expected читаются в разные моменты и создают ложную missing запись. Duplicate с opposite-sign correction скрывается в SUM. Отсутствующая валюта не попадает в inner join.

Recovery protocol¶

Зафиксировать input cut, generation и нормализацию units; не сравнивать плавающие интервалы.
Сопоставить exact key sets с FULL OUTER JOIN, выявить missing/extra/duplicate.
Сравнить суммы по business dimensions и проверить debit/credit invariants.
Разделить recoverable transport gaps, payload conflicts и реальные domain corrections.
Replay только разрешённые identities либо провести новую compensating posting; сохранить связь correction→exception→original.
Повторить сверку на том же cut и получить согласованное закрытие exception.

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

Exact key comparisons дороже hash summaries, но диагностируют причину. Hash/total контроль подходит как early alarm, а не финансовое доказательство. Маленький grace period быстрее обнаруживает ошибки и увеличивает false positives late events.

FinTech и iGaming¶

Settlement file PSP и authoritative ledger независимы от reporting pipeline. Для bets сверяются принятые ставки, результаты, wallet movements и re-settlement revisions; итоговое net значение без IDs не обнаружит все двойные выплаты.

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

Повторно используйте reconcile.py и SQL lab. Инъекция двух offsetting amount errors должна обнаруживаться на уровне ключей/деталей, а не только grand total. Учебные суммы не являются показателями нагрузки.

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

Строить expected из target; сравнивать разные cuts; автоматически DELETE extra ledger rows; использовать float для денег; закрывать exception без проверенной correction.

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

Отличие от DQ? DQ проверяет свойства данных; сверка проверяет соответствие независимых свидетельств на заданном cut.

Что делать при одинаковой сумме и разных IDs? Считать расхождение незакрытым и исследовать key-level differences.

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

PostgreSQL isolation — 17.