Real-time Antifraud Architecture¶
Тип материала — глубокий архитектурный разбор. HYPOTHETICAL — вход 10 000 событий/с, сигнал 20+ ставок игрока за 60 секунд и целевой decision budget 200 мс. Эти числа задают учебные условия.
Три пути решения¶
flowchart LR
A[Bet API] --> R[Redis atomic rules]
R --> D[Inline decision]
D --> K[Kafka audit via outbox]
K --> F[Flink keyed windows]
F --> S[Versioned signals]
S --> D| Вариант | Область решения | Цена и условие применения |
|---|---|---|
| A. API → Redis → decision → Kafka audit | Синхронные bounded counters | Подходит для коротких правил, если доступен актуальный key scope и согласована политика timeout |
| B. Kafka → Flink → signals → Decision API | Асинхронные признаки и review | Event-time и корреляция по ключу, но API может видеть лишь последний опубликованный сигнал |
| C. Гибрид | Inline guards и async enrichment | Быстрые правила защищают критический путь. Более сложные сигналы требуют freshness и объяснимого fallback |
Контракт и окно¶
Решите, что считается ставкой для velocity. Requested attempts могут служить сигналом повторных попыток, accepted bets — другой метрикой. Dedup identity включает tenant, player и logical request ID. Для учебного правила count ≥ 20 на окне [t−60 с, t) фиксируйте единицы и границы. При проверке текущего события решите, входит ли оно в decision count. Redis script выполняет pruning, проверку identity и update атомарно внутри одного scope. Redis Cluster требует совместимый hash slot для связанных ключей. Объём работы script ограничивается, иначе hot key ухудшит tail latency.
Flink keyed state группирует события по player. Watermark задаёт прогресс event time, allowed lateness — допустимое запаздывание. Коррекция окна публикует новую signal revision. Уже совершённое действие сохраняет исходный контекст. Просроченный сигнал может инициировать review или ограничение будущих операций через отдельный durable command.
Сбои и повтор¶
Redis timeout оставляет неопределённый исход increment. Повторить можно ту же operation identity в том же atomic script. Защитный срок dedup должен покрывать retry/replay policy. При утрате state новую generation восстановить из durable input и сверить coverage. Старый cache не использовать для безусловного allow. Поведение при outage — явный reject, review или ограниченный fallback по утверждённой risk policy.
Checkpoint Flink относится к состоянию движка и выбранному connector protocol. Внешний signal sink может отставать или восстанавливаться независимо. После restore сверить source offsets, signal frontier, generation и watermark. Decision API получает signal_age и completeness. При lag выбирается degraded policy, а не ожидание произвольного сообщения в Kafka. Ledger guard остаётся отдельным.
Измерения и аудит¶
Decision latency измеряется от приёма API запроса до durable outcome или ответа согласно фиксированному контракту. Разложите её на routing, lookup, rule/model, commit и очередь. Pipeline latency измеряется от source event или ingress до published signal. Отдельно наблюдайте watermark lag, feature age, fallback rate, duplicate conflicts и hot keys. Измерение pipeline не доказывает выполнение бюджета 200 мс для API.
Decision ID, request fingerprint, rule/model version, feature generation и причины fallback фиксируются durable. Аудит публикуется через outbox, а повтор не должен менять сохранённое решение. Prevention происходит до денежного эффекта. Async detection оставляет основание для review и будущего действия.