Real-time antifraud and velocity rules¶
Тип материала — референсная архитектура. HYPOTHETICAL — проектные схемы и контракты. INFERENCE — рекомендации и trade-offs.
Бизнес-задача¶
Обнаруживать всплески операций и не считать повтор запроса новой попыткой.
Функциональные требования¶
Версионировать окно и порог. Явно выбрать события requested или accepted. Разделить prevention и alerts.
NFR и критический путь¶
Sync lookup ограничивается decision budget. Асинхронные signals имеют freshness marker и измеряемый lag.
Компоненты и поток¶
flowchart LR
A["Bet request"] --> B["Identity guard"] --> C["Player window"] --> D["Risk decision"] --> E["Audit and review"]Контракты и владельцы состояния¶
Событие содержит request_id, player, event_time, ingest_time и outcome. Decision journal хранит признаки и rule version.
Транзакционные границы¶
Atomic counter update и dedup в одном key scope. Decision commit и ledger spend имеют отдельные boundaries.
Ordering, deduplication и idempotency¶
Window interval полуоткрытый, late policy и retention заданы. Redis Cluster требует совместимый hash slot для связанных ключей.
Отказ и восстановление¶
Timeout counter создаёт неизвестный результат. Не повторять increment без dedup. Перестроить новое поколение из журнала и сравнить coverage.
Сверка¶
Воспроизвести ключи и окно на фиксированном cut. Сверить alerts с decision evidence.
Мониторинг и алерты¶
Counter timeout, feature age, duplicate count и fallback rate. Для каждого сигнала определить scope, cut и действие оператора. Порог подбирается по согласованному бюджету и наблюдаемой нагрузке.
Технологии и trade-offs¶
Redis подходит для короткого inline path. Flink — для stateful signals с event time. Гибрид требует явной reconciliation.
Вопросы на собеседовании¶
Может ли late event отменить прошлый decision? Оно уточняет evidence, а дальнейшее действие имеет собственную операцию.