# Design an email delivery service like SendGrid: system design interview question

> A multi-tenant email service with uncertain delivery outcomes, delayed bounce reports, shared capacity, and sender reputation risks.

Source: https://sysround.com/questions/design-email-delivery-service-like-sendgrid
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## 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."

## 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

## 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 probe

### 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:** 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+:** 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.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=transactional-email-delivery


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.