Design a malware detection system: system design interview question

How the interviewer opens it

“Design a malware detection service for uploaded files. Users submit files and receive a verdict.”

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

Users and required checks
Volume and read:write mix
File sizes and formats
Work per file
Latency
Verdict meaning
Availability, consistency, and durability
Retention
Security boundary
Scope limits

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

Accept file uploads and provide scan status
Check files with signatures and a supplied machine learning model
Execute selected files in a sandbox
Return a verdict while protecting the service and other tenants

Usually out of scope

Develop signature feeds or machine learning models
Build endpoint antivirus software
Distribute files to end users
Give sandbox code unrestricted internet access

What interviewers ask about

What a verdict means: Each detector gives incomplete evidence. A quiet sandbox or a failed check does not prove that a file is safe.
Hostile files: The service deliberately parses and executes attacker-controlled content. One successful exploit can threaten other files, credentials, and the control plane.
Demand surges: Sandbox work costs much more than static checks. Small changes in file mix can exhaust capacity before submission volume changes.
Repeated submissions and new threats: Identical bytes can need different verdicts after a threat update. Retries and shared results can also expose tenant data or overwrite newer evidence.

Common mistakes

Executes hostile files before establishing an isolation boundary
Treats signature misses or quiet sandbox runs as proof of safety
Calculates capacity from submission count but ignores sandbox duration
Stores one permanent verdict per file hash
Lets failed checks produce a no-threat-found verdict
Acknowledges submissions before the service durably records the file and work

The bar by level

Senior (L5/E5): Calculates static and sandbox capacity. Defines verdict policy, resource limits, tenant isolation, and overload behavior. Handles duplicate jobs, durable acceptance, and versioned results.
Staff (L6+/E6+): Defines the threat model and limits the impact of host compromise. Connects detector thresholds to capacity and residual risk. Explains result validity after threat updates and protects tenant privacy. States guarantees during overload and partial failure. If the interviewer adds country restrictions, defines where files, replicas, and execution can reside.

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

Scope of a strong answer

Core requirements

Accept file uploads and provide scan status
Check files with signatures and a supplied machine learning model
Execute selected files in a sandbox
Return a verdict while protecting the service and other tenants

Usually out of scope

Develop signature feeds or machine learning models
Build endpoint antivirus software
Distribute files to end users
Give sandbox code unrestricted internet access

What interviewers ask about

What a verdict means

Each detector gives incomplete evidence. A quiet sandbox or a failed check does not prove that a file is safe.

Hostile files

The service deliberately parses and executes attacker-controlled content. One successful exploit can threaten other files, credentials, and the control plane.

Demand surges

Sandbox work costs much more than static checks. Small changes in file mix can exhaust capacity before submission volume changes.

Repeated submissions and new threats

Identical bytes can need different verdicts after a threat update. Retries and shared results can also expose tenant data or overwrite newer evidence.

Common mistakes

Executes hostile files before establishing an isolation boundary

Treats signature misses or quiet sandbox runs as proof of safety

Calculates capacity from submission count but ignores sandbox duration

Stores one permanent verdict per file hash

Lets failed checks produce a no-threat-found verdict

Acknowledges submissions before the service durably records the file and work

The bar by level

Senior (L5/E5)

Calculates static and sandbox capacity. Defines verdict policy, resource limits, tenant isolation, and overload behavior. Handles duplicate jobs, durable acceptance, and versioned results.

Staff (L6+/E6+)

Defines the threat model and limits the impact of host compromise. Connects detector thresholds to capacity and residual risk. Explains result validity after threat updates and protects tenant privacy. States guarantees during overload and partial failure. If the interviewer adds country restrictions, defines where files, replicas, and execution can reside.