Design an account takeover detection system: system design interview question

How the interviewer opens it

“Design a system that detects compromised accounts during user activity. The system must respond quickly and avoid unnecessary restrictions on legitimate users.”

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

Scale
Read and write mix
Actions and responses
Available signals
Latency
Availability, consistency, and durability
Legitimate-user impact
Outcome evidence
Retention and privacy
System 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

Collect device, location, and activity signals
Score sign-ins and sensitive account changes
Apply proportionate responses through existing account services
Measure detection quality and harm to legitimate users

Usually out of scope

Build an identity provider or verification service
Detect payment fraud unrelated to account takeover
Detect malware on user devices
Design new authentication protocols

What interviewers ask about

Device and location evidence: Travel, shared networks, and device changes can resemble attacks. An attacker can also use a familiar device or a stolen session.
Responses to suspicious activity: False alarms affect many legitimate users because takeovers are rare. Attackers may also control the channels that the system uses for verification.
Activity volume and timeliness: The system must decide within 50 ms while context can lag. Concurrent restrictions and account changes must still produce one safe commit order.
Evidence of detection quality: Labels arrive late and cover only some attacks. The system's own responses change which outcomes it can observe.

Common mistakes

The design treats a new device or location as proof of compromise.
The system applies broad account locks when evidence or dependencies are uncertain.
The detector treats client claims or successful verification as confirmed evidence.
The action service checks restrictions before an uncoordinated sensitive change.
The service acknowledges records before a durable commit across zones.
The evaluation ignores delayed outcomes, user harm, or deletion from logs and derived data.

The bar by level

Senior (L5/E5): Meets latency with separate context updates. Coordinates restrictions with final action commits. Handles zone loss, stale data, and duplicate events. Measures delayed outcomes and user harm.
Staff (L6+/E6+): Defines one enforceable safety boundary across account services. Proves commit order and acknowledgement guarantees during failures. Controls feedback bias and policy releases. Implements deletion across logs, snapshots, context, devices, and backups.

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 an account takeover detection system
Reported date not specified
Source snapshot: Nov 12, 2026
View source

How the interviewer opens it

“Design a system that detects compromised accounts during user activity. The system must respond quickly and avoid unnecessary restrictions on legitimate users.”

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

Collect device, location, and activity signals
Score sign-ins and sensitive account changes
Apply proportionate responses through existing account services
Measure detection quality and harm to legitimate users

Usually out of scope

Build an identity provider or verification service
Detect payment fraud unrelated to account takeover
Detect malware on user devices
Design new authentication protocols

What interviewers ask about

Device and location evidence

Travel, shared networks, and device changes can resemble attacks. An attacker can also use a familiar device or a stolen session.

Responses to suspicious activity

False alarms affect many legitimate users because takeovers are rare. Attackers may also control the channels that the system uses for verification.

Activity volume and timeliness

The system must decide within 50 ms while context can lag. Concurrent restrictions and account changes must still produce one safe commit order.

Evidence of detection quality

Labels arrive late and cover only some attacks. The system's own responses change which outcomes it can observe.

Common mistakes

The design treats a new device or location as proof of compromise.

The system applies broad account locks when evidence or dependencies are uncertain.

The detector treats client claims or successful verification as confirmed evidence.

The action service checks restrictions before an uncoordinated sensitive change.

The service acknowledges records before a durable commit across zones.

The evaluation ignores delayed outcomes, user harm, or deletion from logs and derived data.

The bar by level

Senior (L5/E5)

Meets latency with separate context updates. Coordinates restrictions with final action commits. Handles zone loss, stale data, and duplicate events. Measures delayed outcomes and user harm.

Staff (L6+/E6+)

Defines one enforceable safety boundary across account services. Proves commit order and acknowledgement guarantees during failures. Controls feedback bias and policy releases. Implements deletion across logs, snapshots, context, devices, and backups.