Design a CAPTCHA service like reCAPTCHA: system design interview question

How the interviewer opens it

“Design a CAPTCHA service that websites use to distinguish humans from automated clients. It must support high request volumes with little user effort. The service must prevent challenge replay.”

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

Traffic
Read:write mix
Customer integration
User effort
Latency
Lifetime and attempts
Lost responses and retries
Consistency and availability
Location and durability
Exclusions and privacy

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

Issue challenges for a customer site and action
Check answers and issue short-lived proofs
Verify each proof for one protected operation
Control automated abuse and unnecessary user effort

Usually out of scope

Train new challenge or risk models
Replace customer authentication or fraud checks
Guarantee that every automated client fails

What interviewers ask about

Challenge and proof lifetime: Attackers can submit answers and proofs in parallel. A valid signature does not show whether an earlier request consumed the proof.
Lost responses and retries: A lost response makes a retry resemble replay. The service must preserve a successful result beyond proof expiry without permitting another operation.
Attacker-generated load: Attackers can create expensive work without solving challenges. Stronger challenges can also increase cost and reject legitimate users.
Customer boundaries: A public site key permits browser access but cannot authorize server verification. Each proof must remain limited to its customer and action.

Common mistakes

Treats a valid signature as a single-use guarantee.
Omits customer and action checks during verification.
Rejects safe retries after proof expiry or lets retries authorize another operation.
Trusts browser signals as facts.
Focuses on puzzle difficulty and ignores user effort or accessibility.
Uses stale replicas for proof consumption during a fault.

The bar by level

Senior (L5/E5): Defines safe retries beyond proof expiry and enforces customer boundaries. Handles concurrent answers, lost responses, zone failures, and attacker-created load. Measures user effort.
Staff (L6+/E6+): Defines regional authority and the customer operation contract. Resolves receipt retention, key retention, failover, durability, and latency trade-offs. Sets measurable abuse and privacy limits.

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 CAPTCHA service like reCAPTCHA
Reported date not specified
Source snapshot: Nov 12, 2026
View source

How the interviewer opens it

“Design a CAPTCHA service that websites use to distinguish humans from automated clients. It must support high request volumes with little user effort. The service must prevent challenge replay.”

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.

Scope of a strong answer

Core requirements

Issue challenges for a customer site and action
Check answers and issue short-lived proofs
Verify each proof for one protected operation
Control automated abuse and unnecessary user effort

Usually out of scope

Train new challenge or risk models
Replace customer authentication or fraud checks
Guarantee that every automated client fails

What interviewers ask about

Challenge and proof lifetime

Attackers can submit answers and proofs in parallel. A valid signature does not show whether an earlier request consumed the proof.

Lost responses and retries

A lost response makes a retry resemble replay. The service must preserve a successful result beyond proof expiry without permitting another operation.

Attacker-generated load

Attackers can create expensive work without solving challenges. Stronger challenges can also increase cost and reject legitimate users.

Customer boundaries

A public site key permits browser access but cannot authorize server verification. Each proof must remain limited to its customer and action.

Common mistakes

Treats a valid signature as a single-use guarantee.

Omits customer and action checks during verification.

Rejects safe retries after proof expiry or lets retries authorize another operation.

Trusts browser signals as facts.

Focuses on puzzle difficulty and ignores user effort or accessibility.

Uses stale replicas for proof consumption during a fault.

The bar by level

Senior (L5/E5)

Defines safe retries beyond proof expiry and enforces customer boundaries. Handles concurrent answers, lost responses, zone failures, and attacker-created load. Measures user effort.

Staff (L6+/E6+)

Defines regional authority and the customer operation contract. Resolves receipt retention, key retention, failover, durability, and latency trade-offs. Sets measurable abuse and privacy limits.