How the interviewer opens it
“Design a service that sends transactional email for external applications. It must support delivery retries, bounce reports, tenant isolation, and sender reputation management.”
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 and traffic distribution
- Message size and API traffic
- Latency
- Durability and availability
- Delivery meaning and retries
- Tenant boundaries
- Sender reputation
- Bounce reports and suppressions
- Retention and repeated requests
- Service 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
- Accept email from tenant applications and return a durable message identifier.
- Report message status through an API and webhooks.
- Retry temporary failures and process bounce and complaint reports.
- Enforce tenant limits, recipient suppressions, and sender reputation rules.
Usually out of scope
- Marketing campaigns and contact lists.
- Attachments and email template tools.
- Recipient mailbox storage.
- A new SMTP implementation.
- Guarantees about inbox placement or message reads.
What interviewers ask about
- Delivery attempts
- A recipient server can accept an email before the connection fails. A retry can send a second copy.
- Bounce and complaint reports
- Reports can arrive late, repeat, or refer to an earlier attempt. Incorrect reports can stop valid email.
- Tenant isolation
- Tenants share workers and recipient providers. One tenant can consume capacity even when its messages repeatedly fail.
- Sender reputation
- Recipient providers judge sender domains and IP addresses. One tenant can damage delivery for unrelated tenants that share those resources.
Common mistakes
- Treating API acceptance or SMTP acceptance as proof of inbox delivery.
- Promising exactly-once email through an idempotency key alone.
- Retrying permanent failures or letting several layers retry the same message.
- Ignoring delayed bounce reports and recipient suppressions.
- Using one queue or IP pool without a tenant isolation policy.
- Treating sender authentication as a complete reputation strategy.
The bar by level
- Senior (L5/E5)
- Explains ambiguous SMTP outcomes and worker recovery. Designs fair dispatch, tenant-scoped suppressions, report correlation, and provider limits. Separates sender authentication from reputation control.
- Staff (L6+/E6+)
- Defines failure boundaries across acceptance, transport, reports, and reputation. Quantifies backlog recovery and shared IP risk. Explains abuse response and isolation costs. Assess regional recovery only if the interviewer explores that optional follow-up. Do not penalize candidates who omit regional recovery from the core design.