Online casino event processing¶

Раздел 06

Тип материала — референсная архитектура. HYPOTHETICAL — проектные схемы и контракты. INFERENCE — рекомендации и trade-offs.

Бизнес-задача¶

Связать game round, stake, outcome и win posting при повторных vendor callbacks.

Функциональные требования¶

Идентифицировать session и round, проверять game/provider contract, обрабатывать rollback и incomplete round.

NFR и критический путь¶

Синхронные balance mutations требуют durable result. Телеметрия сессии может задерживаться отдельно.

Компоненты и поток¶

flowchart LR
 A["Game provider"] --> B["Callback validator"] --> C["Round state"] --> D["Wallet ledger"] --> E["Event consumers"]

Контракты и владельцы состояния¶

Contract содержит vendor, player, session, round, action, external_tx_id, currency и amount. Result owner provider. Ledger owns деньги.

Транзакционные границы¶

Проверка round transition, posting и inbox commit вместе в выбранной границе. Для remote ledger применять stable operation key.

Ordering, deduplication и idempotency¶

Dedup по provider namespace и external transaction. Same ID/different payload — конфликт. Win-before-stake обрабатывается по контракту vendor.

Отказ и восстановление¶

Подтвердить timeout lookup, восстановить round evidence и отправить в review при missing predecessor. Rollback после commit оформляется reversal.

Сверка¶

Сверить vendor round totals, stake/win postings и voids. Выделить незакрытые раунды.

Мониторинг и алерты¶

Unknown outcomes, incomplete rounds, duplicate conflicts и wallet lag. Для каждого сигнала определить scope, cut и действие оператора. Порог подбирается по согласованному бюджету и наблюдаемой нагрузке.

Технологии и trade-offs¶

Одна DB упрощает state guard. Асинхронная интеграция требует pending и SLA по recovery, определяемого владельцем.

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

Можно ли принять win по session telemetry? Денежный эффект требует авторитетного callback и валидного round contract.