iGaming data platform and regulatory reporting¶
Тип материала — референсная архитектура. HYPOTHETICAL — проектные схемы и контракты. INFERENCE — рекомендации и trade-offs.
Бизнес-задача¶
Выпускать проверяемые отчёты по нескольким источникам и юрисдикциям.
Функциональные требования¶
Хранить versioned input cuts, bet lifecycle, settlements, ledger и правила формы. Воспроизводить старую публикацию.
NFR и критический путь¶
Operational queries и backfill изолированы. Close deadline зависит от обязанности и полноты данных.
Компоненты и поток¶
flowchart LR
A["Authoritative sources"] --> B["Immutable landing"] --> C["Validated transformations"] --> D["Publication registry"] --> E["Regulatory delivery"]Контракты и владельцы состояния¶
Каждый dataset manifest несёт source cuts, hashes, policy version, tenant и jurisdiction. Publication registry владеет версией отчёта.
Транзакционные границы¶
Файлы пишутся в staging. Pointer переключается после validation/approval. External delivery подтверждается отдельно.
Ordering, deduplication и idempotency¶
Retries используют generation key и fixed input cut. Late correction создаёт restatement с lineage.
Отказ и восстановление¶
Partial export не публикуется. Восстановить pins и пересобрать. Сбой отправки разрешить lookup registry/receipt с тем же submission reference.
Сверка¶
Сравнить keys, money by currency, status counts и lineage до journal. Разделить coverage и юридическую приемлемость.
Мониторинг и алерты¶
Close blockers, stale snapshots, failed approvals и missing receipts. Для каждого сигнала определить scope, cut и действие оператора. Порог подбирается по согласованному бюджету и наблюдаемой нагрузке.
Технологии и trade-offs¶
Warehouse упрощает управление вычислениями. Lakehouse обеспечивает immutable raw history при дополнительных governance обязанностях.
Вопросы на собеседовании¶
Зачем хранить отчёт до исправления? Для воспроизведения прежнего выпуска и доказательства основания restatement.