Design a credential breach monitoring service: system design interview question

How the interviewer opens it

“Design a service that checks credentials against known breach datasets. Support large dataset imports and private checks without collecting plaintext passwords.”

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

Meaning of a credential check
Source format
Stored scale
Traffic and read-to-write ratio
Import bursts
Latency and freshness
Password query privacy
Account access
Consistency and durability
Security boundaries and exclusions

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

Import approved breach datasets.
Check whether a password appears in the global password corpus.
Show breach names for an email address after the user proves control.
Notify verified subscribers about new account exposures.

Usually out of scope

Obtain breach datasets.
Crack password hashes.
Test credentials against other services.
Recover passwords from breach records.
Build an email delivery service.

What interviewers ask about

What a password check reveals: A request can avoid plaintext yet still reveal useful password clues. Common passwords and repeated requests make this risk worse.
Import visibility and correctness: Large imports can fail or contain duplicate records. Partial releases can produce false answers and false alerts.
Account access and notification reliability: Account records reveal sensitive history. Subscription races and delivery failures can expose records, miss alerts, or send duplicate alerts.

Common mistakes

The design treats a complete password hash as a private query.
The candidate confuses global password membership with proof that an email-password pair appeared together.
The design ignores password byte rules or assumes all source hash formats support the same lookup.
The candidate estimates query counts but ignores the bandwidth cost of suffix responses.
The service exposes account breach records before the user proves email control.
The design lets partial imports affect results or trigger alerts.

The bar by level

Senior (L5/E5): Sizes prefix responses and bandwidth. Defines complete releases, resumable imports, and recoverable alerts. Handles verification abuse and subscription races.
Staff (L6+/E6+): Defines supplier and client trust boundaries. Explains when prefix privacy fails. Plans stronger privacy, source removal, and key rotation without unsupported guarantees.

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 credential breach monitoring service
Reported date not specified
Source snapshot: Nov 12, 2026
View source

How the interviewer opens it

“Design a service that checks credentials against known breach datasets. Support large dataset imports and private checks without collecting plaintext passwords.”

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

Meaning of a credential check

Source format

Stored scale

Traffic and read-to-write ratio

Import bursts

Latency and freshness

Password query privacy

Account access

Consistency and durability

Security boundaries and exclusions

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

Import approved breach datasets.
Check whether a password appears in the global password corpus.
Show breach names for an email address after the user proves control.
Notify verified subscribers about new account exposures.

Usually out of scope

Obtain breach datasets.
Crack password hashes.
Test credentials against other services.
Recover passwords from breach records.
Build an email delivery service.

What interviewers ask about

What a password check reveals

A request can avoid plaintext yet still reveal useful password clues. Common passwords and repeated requests make this risk worse.

Import visibility and correctness

Large imports can fail or contain duplicate records. Partial releases can produce false answers and false alerts.

Account access and notification reliability

Account records reveal sensitive history. Subscription races and delivery failures can expose records, miss alerts, or send duplicate alerts.

Common mistakes

The design treats a complete password hash as a private query.

The candidate confuses global password membership with proof that an email-password pair appeared together.

The design ignores password byte rules or assumes all source hash formats support the same lookup.

The candidate estimates query counts but ignores the bandwidth cost of suffix responses.

The service exposes account breach records before the user proves email control.

The design lets partial imports affect results or trigger alerts.

The bar by level

Senior (L5/E5)

Sizes prefix responses and bandwidth. Defines complete releases, resumable imports, and recoverable alerts. Handles verification abuse and subscription races.

Staff (L6+/E6+)

Defines supplier and client trust boundaries. Explains when prefix privacy fails. Plans stronger privacy, source removal, and key rotation without unsupported guarantees.