Design a temporary email service
Overview
This question evaluates a candidate's ability to design scalable, highly available, and privacy-focused email ingestion systems, probing competencies in distributed systems, networking (SMTP/MX), storage lifecycle management, rate limiting, security/privacy, and observability.
Confluent
Jul 27, 2025, 12:00 AM
Software Engineer
Technical Screen
System Design
0
0
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).
Solution
Login required
Show