Real-time fraud detection¶

Раздел 05 · Редакционный стандарт

Тип материала — референсная архитектура. HYPOTHETICAL — схемы и операции. INFERENCE — инженерные рекомендации и критерии выбора. Внешние контракты ограничены источниками ниже.

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

Принять решение до денежного эффекта при неполных и запаздывающих признаках.

Требования¶

Разложить deadline на routing, feature fetch и inference. Определить policy деградации по риску. Сохранять model version и reason codes.

Поток данных и владение состоянием¶

flowchart LR
 A["Transaction ingress"] --> B["Kafka"]
 B --> C["Streaming features"]
 C --> D["Redis projection"]
 D --> E["Decision service"]

Input log и decision journal владеют своими фактами. Redis хранит serving state.

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

Decision record хранит provenance. Ledger отдельно защищает расход. Engine checkpoint и Redis commit отделены.

Порядок и идемпотентность¶

Окна по event time. Dedup до counter update. Поздние события корректируют признаки без переписывания старого решения.

Нормальная последовательность¶

sequenceDiagram
 participant A as Transaction ingress
 participant B as Kafka
 participant C as Streaming features
 participant D as Redis projection
 A->>B: Publish transaction event
 B->>C: Apply unique event to event-time window
 C-->>B: Return versioned feature snapshot
 B->>D: Update Redis serving generation

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

sequenceDiagram
 participant B as Kafka
 participant C as Streaming features
 participant E as Recovery operator
 B->>C: Redis restore lags engine progress
 Note over B,C: Outcome becomes uncertain
 E->>C: Rebuild feature generation from durable input
 E->>B: Resume from verified boundary

После Redis loss перестроить generation и переключить после проверки completeness. Для stale features применить утверждённую degraded policy.

Сверка¶

Сравнить input coverage и features на одном cut. Labels анализировать с их задержкой.

Протокол решения. Для каждой попытки храните request ID, feature window end, generation, model version, outcome и причину fallback. Если события пришли вне порядка, в первую очередь восстановите окно признаков. Обработка новых событий может продолжаться с ранее опубликованной полной generation по согласованной policy. Допустимость stale read зависит от риска и максимальной задержки. По результатам offline replay сравнивайте решения на одинаковых версиях features и модели.

Наблюдаемость¶

Feature age, fallback rate, skew и drift.

Безопасность и применимость требований¶

Минимизировать PII. Ограничить доступ к model evidence.

Альтернативы и trade-offs¶

Sync gate защищает до эффекта, async monitoring имеет более свободный latency budget.

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

Можно ли доказать полноту Redis checkpoint-ом? Для этого нужна отдельная сверка serving state.