System Design Interview
Email service inspired by Gmail: a mailbox store partitioned by user, sending through a delivery queue with SMTP retries, attachments stored once in object storage, an inbox cache, a per-user search index fed from a mail event stream, spam filtering with SPF, DKIM, DMARC and a classifier, push sync over open connections, and daily send limits. A teaching design.
See why one server holding every mailbox runs out of room on every axis.
What was missing: Nothing yet.
Why that's risky: Mailboxes only grow, and attachments make them huge. Sending waits on other providers' servers, and searching scans a whole mailbox.
What gets added: One server that stores every mailbox, sends outgoing mail itself, and searches by scanning messages.
Trade-offs: Simple, but storage, sending and search all compete on one machine.
Store mail partitioned by user, and take delivery off the request path.
What was missing: One machine stored everything and delivered mail while the user waited.
Why that's risky: Attachments sit in the mailbox store and bloat it, every inbox open reads the store, and search still scans messages.
What gets added: A mailbox store partitioned by user, so one user's mail sits together and newest first, with a stateless mailbox service in front. Sending saves to the Sent folder and queues the email. Delivery workers hand it to other providers over SMTP with retries, or file it straight into a local recipient's mailbox.
Trade-offs: Partitioning by user makes one mailbox fast and cross-user queries impossible. Email doesn't need them.
Keep big files out of the mailbox store, and open the inbox from memory.
What was missing: Attachments bloated the mailbox store, and every inbox open read it.
Why that's risky: Search still scans messages, nothing filters spam, and clients have to poll to see new mail.
What gets added: Attachments in object storage, each unique file stored once however many emails carry it, downloaded through short-lived signed links. A cache of the first page of each active user's inbox, updated as mail arrives.
Trade-offs: Storing each file once saves a lot of space (one attachment sent to 500 people is stored once), but deleting it needs reference counting.
Make search instant, and keep spam out of the inbox.
What was missing: Search scanned messages, and spam went straight to the inbox.
Why that's risky: Clients still poll for new mail, nothing stops a hijacked account sending thousands of emails, and there is one load balancer.
What gets added: Every new or changed message goes onto a stream, and an indexer adds it to its owner's search index of words, senders, dates and labels. Delivery checks sender authentication (SPF, DKIM, DMARC), sender reputation and a classifier, and files spam in the spam folder.
Trade-offs: A message becomes searchable a second or two after it arrives.
Show new mail instantly, stop abuse, and survive Monday morning.
What was missing: Clients polled for new mail, sending had no limits, and nothing watched delivery delay.
Why that's risky: Remaining risk is low. A newsletter to millions still takes minutes to deliver, by design.
What gets added: A sync gateway that holds a connection to each signed-in client and pushes new mail as it arrives, a rate limiter with daily send caps per account, a second load balancer, a replicated mailbox store, index replicas, more instances, and monitoring of delivery delay, bounce and spam rates and index lag.
Trade-offs: Holding a connection per signed-in client costs memory on the gateways, but removes constant polling.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
