系统设计 Lab
实时 fraud detection 就是把 streaming features 和一个 model 裹进一个很紧的 synchronous latency 预算里。
调节交易速率、decision latency 预算、feature window、model inference 时间、追踪的 entity 数，以及 feedback 延迟。架构会从 static rules，演进到 batch ML scoring，再到带 synchronous scoring 的 streaming features，再到带 retraining 的 feedback loop，最终到大规模的 graph features。
分步讲解
一步一步把它想清楚
要点
常规演进场景
从左到右点击，就是预设的演示路径。每张卡片都会改变 workload 输入。
推荐形态
当前架构路径
Clients
Payment client 提交每一笔交易，等一个 allow、deny 或 review 决策
Scoring API
Scoring API 在 latency 预算内编排这次 synchronous 决策
Decision gate 执行 fail-open 或 fail-closed 策略，返回最终裁决
Real-time features
Stream processor 从 event stream 维护按窗口的 velocity 计数和聚合
Feature store 低延迟地把预算好的 per-entity feature 提供给 scorer
Model + rules
Rules engine 在 model 之前或并行地评估确定性 rule 和 hard block
Model service 返回一个欺诈概率，gate 把它和 rule 的裁决合并
Graph store 把共享的卡、设备和地址连起来，暴露有组织的 ring
Feedback + retrain
Label store 把 chargeback 和争议结果收集为 ground-truth label
Training pipeline 用新 label 做 retrain 以跟上漂移的 fraud 模式，并发布新 model
瓶颈
Scoring 路径负载
Decision 预算余量
Stream state 体量
Graph linking 负载
Model drift 风险
为什么会变
决策权衡
有出处支撑的规则
这些是模型背后那些经得起时间考验的 system design 论断。而 slider 的具体阈值，则被刻意标注为教学用的假设。
有状态的 stream processing 实时维护按窗口的聚合
Flink 为每个 entity 保留 keyed state 和窗口，于是 velocity 计数和聚合持续更新，而不是每个请求都重算。
Apache Flink Docs一个持久、可重放的 log 支撑 feature 和 feedback 这两条 stream
Kafka 给交易和 label 两条 stream 提供了有序、可重放的骨干，正是它让 feature 能被重算、model 能从历史 retrain。
Apache Kafka Docs一个 feature store 把同一套 feature 既低延迟地 online 服务，又 offline 供 training
feature store 解决 online/offline skew：synchronous scorer 快速读到新鲜 feature，而 training 读到一致的历史值。
Feast DocsFraud detection 是一个带 drift 的 anomaly / novelty-detection 问题
欺诈很罕见、模式还随时间漂移，所以检测被框定为 outlier/novelty detection，需要新鲜 label 和频繁 retraining，而不是一个静态 model。
scikit-learn教学用假设
- decision 预算被拆给 feature lookup、model inference 和 rules；剩余余量就是扣掉 model latency 之后还剩的部分。
- 单节点的 scoring、feature-lookup 和 stream-state 预算都是保守的教学数字，不是厂商上限。
- graph linking 成本被建模为随追踪的 entity 数和交易速率一起增长；真实系统会把其中大部分 offline 预算好。