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.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Technical Screen rounds at Confluent.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Confluent during technical interviews.

Design a temporary email service | Confluent Interview Question

Quick 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.

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).

Quick Overview

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).

Design a temporary email service

Quick Overview

Design a Disposable Email Service with Auto-Expiring Addresses

Functional Requirements

Non-Functional Requirements

Specify and Discuss

Architecture, Data, and Trade-offs

Solution

Comments (0)

Design a temporary email service

Quick Overview

Design a Disposable Email Service with Auto-Expiring Addresses

Functional Requirements

Non-Functional Requirements

Specify and Discuss

Architecture, Data, and Trade-offs

Solution

Comments (0)