Design a real-time spam-and-abuse filter that inspects messages as they flow through a chat platform and blocks, quarantines, or rate-limits the bad ones before they reach recipients. It is an inline gate on the delivery path, so it must score a message and return a verdict fast enough that senders never perceive a delay.

Operating context. Every message is evaluated: peak throughput is around 500,000 messages/sec, and the filter sits synchronously in front of delivery, so it may add at most a few tens of milliseconds at p99 or it becomes the bottleneck. A verdict combines cheap deterministic rules (blocklists, sender velocity, link reputation) with a machine-learned score, and the definition of spam shifts hourly as spammers adapt, so models and rules must be updatable without redeploying the fleet. User reports feed a labeling and retraining loop. Because the filter is on the critical path, you must decide what happens when scoring is slow or unavailable: fail open (deliver) or fail closed (block).

Out of scope. Message delivery and storage themselves, media and attachment scanning, account-level ban enforcement and the appeals workflow, and the model-training infrastructure internals. Assume you receive an authenticated message with sender, recipient, and content already extracted.

What to produce. A high-level architecture covering: the inline scoring path and its latency budget, how deterministic rules and the ML score are combined into a verdict, how per-sender velocity and reputation signals are computed at this throughput, how models and rules are updated live, the feedback loop from user reports back into labeling, and your fail-open-versus-fail-closed policy with its blast radius. Sketch the components and the request flow; checkpoints will probe the latency budget and the live-update path.