Confluent·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

Jun 2026Remote

Summary

System design round at Confluent for a software engineer role. One meaty question that took the whole session, and I left feeling like I'd only scratched the surface of what they actually wanted.

Questions Asked (1)

Design a disposable email service that generates short-lived inbox addresses on demand. The addresses need to look like real human names to avoid spam filters, must be globally unique, and the system needs to handle hundreds of millions of new addresses per day without ever deleting old ones. Walk through generation strategy, uniqueness checking, storage, and lookup latency.

System DesignAlgorithms & Data StructuresTechnical Trade-offs

Author's notes

I jumped straight to Bloom filters for the uniqueness check which felt smart in the moment, but then the interviewer pushed on false positives and I kind of fumbled.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then propose a generation strategy that combines human-like name components with a unique suffix or encoding. Address uniqueness through a distributed ID generator or probabilistic data structure, and design storage and lookup for low latency and high throughput. Discuss trade-offs between consistency, latency, and cost.

Pro tip: Emphasize that the system must never delete old addresses, so storage grows unbounded; propose a tiered storage strategy with hot/warm/cold data and consider using a compact encoding to reduce storage footprint.

1. Clarify Requirements and Scale

Ask about expected read/write patterns, latency requirements, and whether addresses need to be human-readable or just look human-like. Confirm the scale: hundreds of millions per day implies ~2-3k writes/sec average, but plan for bursts.

2. Design Address Generation

Propose generating addresses from a large pool of first and last names, combined with a unique numeric or alphanumeric suffix (e.g., john.doe.1234@domain). Ensure the format resembles real human emails and avoids patterns that spam filters flag.

3. Ensure Global Uniqueness

Use a distributed unique ID generator (e.g., Snowflake) to create the suffix, or use a centralized counter with sharding. Alternatively, use a hash of the name components plus a random salt, and check for collisions probabilistically.

4. Design Storage and Lookup

Store addresses in a distributed key-value store (e.g., Cassandra, DynamoDB) with the address as the key and metadata as the value. Use consistent hashing for partitioning. For low-latency lookup, cache hot addresses in memory (e.g., Redis) and use SSD-based storage for cold data.

5. Address Trade-offs and Scalability

Discuss trade-offs: strong vs. eventual consistency for uniqueness, cost of storage vs. latency, and the impact of never deleting data. Propose sharding, replication, and tiered storage to handle growth.

Key Points to Mention

Human-like name generation using a large corpus of first/last names and patterns
Uniqueness enforcement via distributed ID generation (e.g., Snowflake) or collision-resistant hashing
Storage design: distributed KV store with partitioning and replication
Low-latency lookup: caching, indexing, and possibly a bloom filter for existence checks
Scalability: sharding, horizontal scaling, and handling write bursts
Trade-offs: consistency vs. availability, storage cost vs. latency, and the implications of never deleting data

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.