Design an email spam detection system

Read the full interview experience this question came from →

Quick Overview

This interview question evaluates ML product requirements, data/labeling, modeling, serving architecture, evaluation, monitoring, and trade-offs in a realistic interview setting. A strong answer for Design an email spam detection system states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Design an email spam detection system

Company: Amazon

Role: Software Engineer

Category: ML System Design

Difficulty: hard

Interview Round: Technical Screen

Design an end-to-end email spam detection system. Cover: problem definition and labeling; data sources and collection (inbox, user reports, honeypots); feature engineering (content, headers, sender reputation, network signals); model choices and training (baseline rules vs. ML, online learning); serving architecture and latency/throughput constraints; thresholding and calibration; evaluation metrics (precision/recall, ROC-PR, cost-weighted metrics); abuse/adversarial defenses and feedback loops; cold start, concept drift, and model retraining cadence; online experimentation (A/B, ramp, guardrails); monitoring, logging, and rollback strategy; privacy and compliance considerations.

Overview: This interview question evaluates ML product requirements, data/labeling, modeling, serving architecture, evaluation, monitoring, and trade-offs in a realistic interview setting. A strong answer for Design an email spam detection system states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Read the full Amazon Software Engineer interview experience this question came from

Amazon logo
Amazon
Aug 10, 2025
hardSoftware EngineerTechnical ScreenML System Design
27
0

Design an email spam detection system

System Design: End-to-End Email Spam Detection

Context

Design an end-to-end system that detects and handles spam emails at scale. Assume you are building for a large consumer email service handling high throughput and strict latency requirements. The design should cover data, ML, serving, experimentation, and operations.

Requirements

  1. Problem Definition and Labeling
    • Define the objective(s) and action outcomes (e.g., block, quarantine, inbox with banner).
    • Labeling sources and policies.
  2. Data Sources and Collection
    • Inbound traffic, user reports, honeypots, abuse teams, reputation feeds.
    • Collection, sampling, retention, and governance.
  3. Feature Engineering
    • Content features (text, URLs, attachments), headers, sender/domain/IP reputation, network/behavioral signals.
  4. Model Choices and Training
    • Baseline rules, supervised ML models, online learning.
    • Handling class imbalance, feature hashing, model calibration.
  5. Serving Architecture and Constraints
    • Placement in the mail pipeline, APIs, latency/throughput targets, caching, fallbacks.
  6. Thresholding and Calibration
    • Score-to-action mapping, per-segment thresholds, calibration methods.
  7. Evaluation Metrics
    • Precision, recall, ROC/PR analysis, and cost-weighted metrics.
  8. Abuse/Adversarial Defenses and Feedback Loops
    • Evasion tactics, spoofing defenses, URL/attachment handling, user feedback integration.
  9. Cold Start, Concept Drift, Retraining Cadence
    • New senders/domains, seasonal drift, automated retraining.
  10. Online Experimentation
    • A/B testing, ramp strategies, guardrails.
  11. Monitoring, Logging, Rollback
    • Real-time and batch monitoring, alerting, safe rollback.
  12. Privacy and Compliance
    • Data minimization, encryption, regional residency, user controls.

Clarifying Questions to Ask Guidance

  • Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
  • State explicit assumptions before making sizing or architecture decisions.
  • Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

  • A scoped requirements summary with concrete non-goals and success metrics.
  • ML-specific data, model, evaluation, serving, and monitoring choices.
  • Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
  • A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

  • What breaks first at 10x traffic or data volume?
  • How would you degrade gracefully during dependency failures?
  • What metrics and alerts would prove the design is healthy after launch?