Design a Distributed Anti-Spam Service

Medium45 min
1 / 30
understanding•11 min read

Problem Statement: An Adversarial Multi-Surface Classification Platform

Frames anti-spam as a latency-bounded, adversarial, cross-surface decision platform rather than a single content filter.

Problem statement

Design a distributed anti-spam service that monitors content streams across a social platform — comment threads, direct messages, user posts, account sign-ups, and profile updates — classifies each event in real time, and takes enforcement action: allow, challenge, delay, quarantine, drop, or account-level action. The service is consumed by many product surfaces through one decision API and one event backbone, and it must keep a durable audit trail for every verdict.

This is not one filter. A comment filter that runs after publish, a messaging filter that must decide before delivery, and a sign-up filter that must decide before account creation have different latency budgets, different error costs, and different adversaries. The design therefore separates four planes: ingestion (getting every content event into one ordered backbone), decision (rules, lightweight models, heavy models, reputation lookups), enforcement (applying verdicts consistently per surface), and learning (reports, appeals, reviewer labels, model retraining).

Why the problem is distinctive

A search backend can retry a query. Anti-spam fights an adversary that watches your behavior and adapts. Three properties dominate the architecture. First, distribution shift is not accidental, it is manufactured: spammers rotate accounts, rephrase text, swap links, and move surfaces the moment one path is blocked. Second, the cost of errors is asymmetric and surface-dependent: quarantining a legitimate message from a real user is a trust wound, while missing one phishing message in a million DMs can cause real harm. Third, latency budgets are contractual: the comment service will not wait 200 ms for a verdict, so the architecture must split cheap synchronous decisions from expensive asynchronous ones.

Public operating baseline

Public evidence establishes that this category operates at enormous scale. Google has reported that Gmail blocks over 100 million spam messages per day and that more than 99.9% of spam is blocked before reaching the inbox. Meta's integrity reports describe removing on the order of a billion fake accounts per quarter, with the large majority detected proactively before any user report. The Imperva 2024 Bad Bot Report measures roughly 32% of all web traffic as automated bad bots, the raw supply of sign-up and comment spam. These are cited industry figures, not requirements for our fictional system.

For capacity planning this answer explicitly assumes a mature social platform with 150 million daily active users, roughly 2.7 billion content events per day across all surfaces, and a 5x event peak. Unless a number is tied to a citation, it is a stated design assumption, target, or budget.

The four architectural planes

  1. Ingestion plane: validated, schema-checked, ordered content events from every surface, with per-surface quotas and priority classes.
  2. Decision plane: a synchronous inline path (denylists, rules, lightweight model, reputation lookup) under a 50 ms p99 budget, and an asynchronous deep path (heavy classifiers, media hashing, graph checks) completing within seconds.
  3. Enforcement plane: per-surface action adapters that apply verdicts idempotently — publish, hide, challenge, quarantine, rate-limit, ban — and report observed outcomes.
  4. Learning plane: user reports, appeals, human review queues, label propagation, drift monitoring, and governed model and rule releases.

A strong interview answer keeps these planes separate. It lets the learning plane improve models without silently changing enforcement semantics, and it lets the enforcement plane degrade per surface without weakening the decision audit trail.

Key Highlights

  • •Anti-spam is an adversarial classification platform, not a single filter; the adversary adapts to every control you deploy.
  • •Inline decisions must complete under 50 ms p99; heavy classification runs asynchronously and updates verdicts within seconds.
  • •Public baseline: Google reports 100M+ spam messages blocked per day and 99.9%+ blocked before the inbox.
  • •The architecture has four planes: ingestion, decision, enforcement, and learning.
  • •Every verdict is durable and auditable; enforcement applies verdicts idempotently per surface.
Lead With the Adversary
State in the first two minutes that your classifier's input distribution is controlled by an active adversary who observes and evades your controls. This instantly distinguishes an anti-spam design from a generic content pipeline.
Do Not Draw One Filter Box
A single 'spam detector' service with no latency split, no enforcement semantics, and no feedback loop fails a serious interview. The inline/async split and the audit ledger are the architecture.

Section Rescue Kit

Buzzwords to use:

Decision LedgerInline vs Deep Path

Safe statements:

  • "I will separate content decision from enforcement: the decision plane may be eventual on deep checks, but every enforcement action is idempotent and audited."
  • "Before selecting services, let me define which decisions must be synchronous, which may complete asynchronously, and which require human review."
Design a Distributed Anti-Spam Service - System Design | WinJob | WinJob