Design a phishing URL detection system: system design interview question

How the interviewer opens it

“Design a service that classifies URLs and websites as safe or potentially malicious. It must detect new phishing campaigns and answer reputation checks quickly.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

What to clarify first

Clients and verdicts
Traffic and read:write ratio
Latency and availability
Discovery and detection delay
Scan budget
Consistency and freshness
Error costs
Retention and record sizes
Deployment and page access
Scope boundaries

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

Scope of a strong answer

Core requirements

Return a URL verdict with its age and reasons.
Inspect new URLs and inspect known URLs again when their evidence expires.
Detect new phishing campaigns across related URLs and websites.
Distribute verdict changes and corrections to the services that answer reputation checks.

Usually out of scope

Train a complete machine learning model.
Analyze full email messages or downloaded programs.
Decide how browsers and mail clients enforce verdicts.
Inspect pages that require a user account.

What interviewers ask about

New phishing campaigns: New campaigns have no reputation history. Attackers change URLs faster than the service can inspect every page.
URL and website identity: Small URL differences can change page behavior. A broad website verdict can also harm unrelated pages or tenants.
Page inspection: The service must execute hostile page content without exposing its own network, credentials, or scan capacity.
Verdict changes and mistakes: A false verdict can affect millions of checks before correction. Late results and stale regions can restore an obsolete decision.

Common mistakes

Treats unknown URLs as safe because no threat feed lists them.
Places page fetches and browser scans on the synchronous check path.
Uses broad domain verdicts without support for shared hosts or compromised pages.
Trusts hostile pages with network access or service credentials.
Ignores scan selection when measuring detection quality.
Provides no correction path for false positives or stale verdicts.

The bar by level

Senior (L5/E5): Budgets scan capacity and defines URL identity. Detects related campaigns. Handles hostile fetches, versioned updates, cache freshness, and false-positive corrections.
Staff (L6+/E6+): Defines guarantees during partitions and source compromise. Controls adversarial scan demand. Measures selection bias and detection delay. Quantifies correction speed and cost trade-offs.

Sources · 1 reference

These records explain where the question appears. A company tag or candidate report does not guarantee a future interview question.

SysRound · 1 record

No company association
Design a phishing URL detection system
Reported date not specified
Source snapshot: Nov 12, 2026
View source

How the interviewer opens it

“Design a service that classifies URLs and websites as safe or potentially malicious. It must detect new phishing campaigns and answer reputation checks quickly.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

What to clarify first

Clients and verdicts

Traffic and read:write ratio

Latency and availability

Discovery and detection delay

Scan budget

Consistency and freshness

Error costs

Retention and record sizes

Deployment and page access

Scope boundaries

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

Scope of a strong answer

Core requirements

Return a URL verdict with its age and reasons.
Inspect new URLs and inspect known URLs again when their evidence expires.
Detect new phishing campaigns across related URLs and websites.
Distribute verdict changes and corrections to the services that answer reputation checks.

Usually out of scope

Train a complete machine learning model.
Analyze full email messages or downloaded programs.
Decide how browsers and mail clients enforce verdicts.
Inspect pages that require a user account.

What interviewers ask about

New phishing campaigns

New campaigns have no reputation history. Attackers change URLs faster than the service can inspect every page.

URL and website identity

Small URL differences can change page behavior. A broad website verdict can also harm unrelated pages or tenants.

Page inspection

The service must execute hostile page content without exposing its own network, credentials, or scan capacity.

Verdict changes and mistakes

A false verdict can affect millions of checks before correction. Late results and stale regions can restore an obsolete decision.

Common mistakes

Treats unknown URLs as safe because no threat feed lists them.

Places page fetches and browser scans on the synchronous check path.

Uses broad domain verdicts without support for shared hosts or compromised pages.

Trusts hostile pages with network access or service credentials.

Ignores scan selection when measuring detection quality.

Provides no correction path for false positives or stale verdicts.

The bar by level

Senior (L5/E5)

Budgets scan capacity and defines URL identity. Detects related campaigns. Handles hostile fetches, versioned updates, cache freshness, and false-positive corrections.

Staff (L6+/E6+)

Defines guarantees during partitions and source compromise. Controls adversarial scan demand. Measures selection bias and detection delay. Quantifies correction speed and cost trade-offs.