Design an AI Content Moderation System

Layered moderation for a large community, inspired by Discord and Reddit: known-bad content matched by hash, a fast classifier that decides most posts in milliseconds, an LLM that reviews the uncertain ones against the written rules, and human moderators for the hardest cases and appeals. A teaching design.

Functional requirements

  • Every new post (text or image) is checked before or right after it appears.
  • Clearly harmful posts are blocked at once; clearly fine posts go live at once.
  • Uncertain posts are decided by a stronger model, and the hardest by people.
  • Content already removed once is blocked instantly if posted again.
  • Users can appeal, and every decision records who or what made it.

Non-functional requirements

  • Posting: p99 < 200 ms including the fast check.
  • Scale: 50M daily members, 5K requests/s at peak.
  • Uncertain posts are decided within minutes.
  • Every decision is kept for audits and appeals.
  • Availability: 99.95%.

How the design evolves

Stage 1: An LLM on Every Post

See why running the biggest model on every post is too slow and too expensive.

What was missing: Nothing yet.

Why that's risky: Over a second per post and a large bill per post; when the LLM is slow, nobody can post.

What gets added: One server that sends every new post to a large LLM and only saves it once the model says it is fine.

Trade-offs: The most accurate single check, applied where it is least needed.

Stage 2: A Fast Classifier First

Decide most posts in milliseconds with a small model.

What was missing: Every post waited on an expensive LLM.

Why that's risky: Posts in the middle band are either let through or blocked by a guess.

What gets added: A small classifier on GPUs scores every post in about 15 ms. High scores are blocked, low scores go live, and every moderation decision is saved with its scores. Feeds read posts through a cache.

Trade-offs: The small model is fast and cheap but misses context, sarcasm and new slang.

Stage 3: An LLM for Uncertain Posts

Spend the expensive model only where it is needed.

What was missing: Borderline posts were decided by the small model's guess.

Why that's risky: A borderline post can be visible for a few minutes before the LLM hides it; hold uncertain posts from large audiences until decided.

What gets added: Posts in the uncertain band (about 10%) are queued. LLM workers judge each one against the written community rules, save the decision with the model's reasoning, and hide the post if needed.

Trade-offs: Accuracy where it matters, at a tenth of the cost of checking everything with the LLM.

Stage 4: Known-bad Hashes and Human Review

Block re-posts instantly and route the hardest cases to people.

What was missing: Spam waves re-posted the same content thousands of times, and nobody handled what the LLM itself was unsure about or what users appealed.

Why that's risky: Moderators see disturbing content; limit exposure per shift and blur images by default.

What gets added: A cache of perceptual hashes of removed content, checked before anything else. Cases the LLM is unsure about, and appeals, go to a human review queue; assignment workers route each case to a moderator by language and topic, and the moderator tool records their decision.

Trade-offs: People are slow and expensive, so they only see what machines can't decide.

Stage 5: Limits, Redundancy and Monitoring

Survive spam floods and remove single points of failure.

What was missing: Bot floods could overwhelm posting, and the load balancer and databases were single points of failure.

Why that's risky: Strict limits on new accounts slow down genuine newcomers.

What gets added: Rate limits per account (stricter for new ones), a second load balancer, sharded post storage, replicated decisions, more classifier capacity, and monitoring of appeal reversals to catch a drifting model.

Trade-offs: Appeal reversals are the best signal that a model needs retraining.

PRISM
System Design Interview
Round 1 of 4 · Architecture Design · 60:00 remaining
PRISM logo PRISM logo
Problems
AI Interview
Interview Challenges
Build & Stress Test NEW
System Architectures
Design & Fix NEW
Interactive Roadmap
System Design Guides Interview Prep Guide
Problems
Today's mission
Notifications
    Theme
    Pricing Community NEW Send feedback Report a problem NEW
    Sign in
    Theme
    Community NEW Send feedback Report a problem NEW
    All problems
    Phase
    Build & Stress Test
    Phase 01: Thinking in Systems
    Upcoming

    Components

    User
    CDN
    Load Balancer
    Server
    Cache
    Database
    Blob Storage
    Search Index
    Queue
    Worker
    Rate Limiter
    Service
    API Gateway
    Reverse Proxy
    WebSocket Server
    Third-party API

    Inspector

    Notes
    Use clear names so your design intent is easy to understand.
    Good
    Name by business meaning
    "Order API", "Restaurant Service"
    Avoid
    Generic names = zero signal
    "Server 1", "API", "Queue"
    A short description for each component makes feedback much better.
    100%
    Start by identifying:
    • Users & entry points
    • APIs & services
    • Databases & storage
    • Traffic flow & scale

    Round 1 of 4 Architecture Design

    Run a simulation to see results.

    Time Remaining
    60:00
    System Design Interview

    What are the core functional requirements?
    What are the key non-functional constraints?

    Questions

    Start Evaluation to unlock questions.

    EVALUATE MODE

    Test yourself like it's the real thing.

    A structured 4-module evaluation that mirrors how top companies assess system design candidates.

    Architecture Design
    Draw your system on the canvas. Define components, connections, and data flow.
    FR & NFR Requirements
    Answer functional and non-functional requirement questions about your design.
    MCQ Round
    Multiple choice questions testing your depth on the chosen system.
    Tradeoff Analysis
    Justify your design decisions and defend your architectural tradeoffs.
    AI Report Generated
    Choose a Problem
    No problem selected
    • 30 min
    • 45 min
    • 60 min
    Round 2 of 4
    MCQ Round
    Answer multiple-choice questions based on your design.

    Exit Interview?

    You're in the middle of an interview session. Leaving now will end your current attempt.

    Your progress will be saved.

    Open a saved design

    Select a design to load into the canvas.

    My Evaluations

    Your past evaluation sessions

    Here’s a simple request flow that follows the expected layer order.

    External User
    →
    Edge CDN → API Gateway → Load Balancer
    →
    Compute App Servers / Services
    →
    DataAccess Cache
    →
    Storage Database / Search Index
    →
    Async Queue → Worker

    Tip: keep arrows moving forward through layers (Edge → Compute → Storage). Avoid sending storage back to compute.

    Evaluation Instructions

    Read the rules carefully before starting. The test auto-submits on refresh.

    Before you start

    • Build your architecture on the canvas. The timer starts when you click Start Evaluation.
    • Don't forget to answer Functional Requirement and Non Functional Requirements.
    • When satisfied with your design, click Next to lock it and view the questions.
    • Please answer final step questions to complete the evaluation.

    Dos

    • Do read each question carefully before answering.
    • Do include required components to maximize component coverage.
    • Do save a copy of your design if you want to keep it before submission.

    Don'ts

    • Don't refresh or close the tab during an active evaluation — this will auto-submit your answers.
    • Don't switch app modes or open another tab while the evaluation is running.
    • Don't attempt to edit the design after clicking Next; the workspace will be locked.

    All the best!!

    Confirm

    Input

    Notice

    Evaluation Report
    Report a problem

    Evaluation Complete

    Generating Your Report

    Hang tight — our AI is evaluating your design…

    Did you know?

    Loading…

    Share feedback

    Tell us what worked well and what we can improve.

    Let's personalize this

    Answer a couple of quick questions so we can tailor your journey and missions.

    Your welcome gift: of Full PRISM Access

    Your Pro access starts as soon as you press Start my journey.

    SYSTEM BRIEF

    System Constraints

    What the system must do — every item is a user-facing behaviour your architecture must support.

      ↑ Engineering Constraints

      These are the failure modes you must design against — latency SLAs, durability targets, traffic ceilings.

        ⇆ Architecture Constraints

        Core Concepts to Master

        Your Journey
        PHASE – –
        0 / 0 0%
        0
        Mock Interview Checklist

        Pick a topic to start

        Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.

        Phase Mastered

        You've conquered this phase. These are the skills you now own:

          +500 XP

          Company Interview Paths

          Progress Summary