Training/Serving Skew in a Velocity Feature

A post-launch audit finds that the model's top feature by importance, card_txn_count_1h, is computed two different ways: online, a Flink job maintains a rolling count per card in Redis using 10-second tumbling sub-buckets summed over the last 6 buckets; offline, the training pipeline back-fills the same feature with a SQL self-join over the transactions table using exact timestamps.

1. Describe a concrete scenario where these two computations disagree for the same transaction, and what effect that has on the model.
2. How would you detect this kind of skew in production before it shows up as a fraud-rate regression?
3. Propose a fix that eliminates the disagreement at its root, not just patches the symptom.