Design a Predictive Alert System (Spam/Abuse)

Problem statement

Design a predictive alert system that ingests user activities—posts, messages, login patterns, account changes, reaction bursts—runs classification and anomaly detection over them, and triggers alerts or automatic enforcement before abuse escalates. The system must operate in real time for inline blocking and near real time for pattern detection, and it must close the loop: every enforcement outcome and human review verdict becomes training signal for the next model generation.

This is not one model behind one API. A post-publish pattern such as a coordinated burst from hundreds of fresh accounts is invisible to any per-event inline check, while a credential-stuffing login must be challenged in milliseconds before the session is granted. The design therefore separates four planes: an ingestion plane that durably captures every behavioral event; a detection plane with an inline synchronous gate and an asynchronous streaming detector; an enforcement plane that maps scores and alerts to a graduated ladder of actions; and a learning plane that turns labels, appeals, and sampling into measured model releases.

Why the problem is distinctive

A recommendation system can retry a ranking. An abuse system cannot retry a missed coordinated attack, and it also cannot silently punish a legitimate user without an explainable, appealable path. Three properties make this design different from a generic analytics pipeline. First, it is adversarial: the input distribution shifts deliberately as attackers adapt, so static thresholds decay and every metric needs a drift story. Second, it has dual latency regimes: a 50 ms inline budget for pre-action gates and a seconds-scale budget for cross-event correlation, and the two regimes share features but not failure modes. Third, it is accountable: enforcement touches speech, money, or access, so decisions carry reason codes, audit trails, appeal SLAs, and jurisdiction-aware retention.

Public operating baseline versus design assumptions

Public evidence shows the category operates at enormous scale. Twitter reported that at its 2018 peak its systems identified and challenged more than 9.9 million potentially spammy or automated accounts per week. Gmail states its AI-powered defenses stop more than 99.9 percent of spam, phishing, and malware and block on the order of 15 billion unwanted emails daily. Meta reports blocking millions of fake-account creation attempts every day and took action on roughly 1.1 billion fake accounts in Q4 2025. Stripe publishes that Radar evaluates more than 1,000 characteristics per transaction in under 100 milliseconds, trained on tens of trillions of data points. These are cited company figures, not requirements for our fictional platform.

For capacity planning this answer explicitly assumes a mature platform with 100 million DAU, 2 billion behavioral events per day, a five-times event peak, 600-byte average events, 0.8 percent automatic enforcement, and 0.05 percent human review. Unless a number is tied to a citation, it is a stated design assumption, target, budget, or illustrative threshold—not a claim about any company's private architecture.

The four architectural planes

1. Ingestion plane: schema-validated event capture, durable streams, replay, and priority classes.
2. Detection plane: inline synchronous gate (denylist bloom, velocity, lightweight model) plus asynchronous streaming detectors (cohort anomalies, graph clusters, sequence models).
3. Enforcement plane: reputation state, graduated action ladder, challenges, review queue, appeals, and audit.
4. Learning plane: label pipelines, sampling, offline training, shadow and canary evaluation, drift monitoring, and governed promotion.

A strong interview answer keeps these planes separate, lets the detection plane degrade without losing durable ingestion, and never lets the learning plane silently change enforcement behavior without a measured release gate.