Design a temporary email service

Q: Design a temporary email service

This is a System Design interview question from Confluent for Software Engineer roles. View the full question and solution on PracHub.

Q: How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

Question

Design a Disposable Email Service with Auto-Expiring Addresses

You are asked to design a receive-only disposable email service (e.g., 10‑minute inboxes) that issues auto-expiring addresses and displays received messages via a web UI and REST API.

Provide a clear, high-level design covering:

Functional Requirements

Create ephemeral email addresses that auto-expire (e.g., after 10 minutes).
Receive inbound email over SMTP and surface messages in near real time.
List, read, and delete messages via Web UI and REST.
Enforce per-inbox and per-user/IP quotas and rate limits.

Non-Functional Requirements

High availability for SMTP ingress and reads; eventual consistency is acceptable for message indexing.
Low-latency display of new messages (p95 < 2–5 seconds from SMTP accept).
Scale to millions of inboxes per day and millions of messages per day.
Strict privacy/security and compliant deletion on TTL expiration.
Cost efficiency with storage lifecycle management.

Specify and Discuss

Requirements and public APIs (create inbox, list messages, get message, delete).
Address generation and TTL semantics.
SMTP ingress: MX records, inbound MTA behavior, acceptance policy.
Spam/abuse controls.
Storage schema with per-message TTL and indexing strategy.
Retrieval via Web UI and REST (including auth model/capability tokens).
Rate limiting and quota.
Privacy/security: isolation, link-safety, attachment handling.
Compliance and deletion guarantees.
Background cleanup processes.
Observability: metrics, logs, tracing, alerts.
Capacity planning and cost controls.

Architecture, Data, and Trade-offs

High-level architecture: MTA → queue/stream → message processor → durable store → cache → API/UI.
Data model: inbox, message, attachment, and indexing entities.
Consistency vs. availability trade-offs for SMTP accept, message availability, and deletion.
Scaling strategies to handle millions of inboxes/messages per day.
Cost control mechanisms (storage lifecycle, attachment limits, rate limiting).