Workspace

Dashboard Learn Handbook Labs Practice library Learning paths Review Insights Studios Mock interviews Notebook

Personal workspace · self-hosted

Search

Jump to a problem, path or page

Email Inbox Synchronization Service · Brief · designlab

Dashboard Learn Handbook Labs Practice library Learning paths Review Insights Studios Mock interviews Notebook

Search

Jump to a problem, path or page

Library ArchitectureEmail Inbox Synchronization Service

✉

Email Inbox Synchronization Service

HLDAdvanced55 minStorage & partitioning Consistency & transactions Search & retrieval Guided lab

All changes saved Not started

01 · Understand the problem

Your mission

Build an inbox with an API service for reads and ingestion, a queue and spam workers for delivery, a mailbox store for metadata and ordered changes, and object storage for immutable bodies. Clients synchronize through retained mailbox sequences; outbound delivery and mail protocol implementation are separate.

02 · Define success

Requirements

Deduplicate ingress under a provider-scoped delivery identity.
Commit mailbox metadata and change entries atomically.
Support revision-checked flag updates and deletion tombstones.
Recover devices whose change cursor is older than retained history.

Open the design canvas Read the analysis first

Design envelope

30,000
peak reads / s: 8,000
writes / s: 250 ms
target read p99: 3000 B
record size

Workload assumptions for this exercise, not measured production limits.

Think about request flow, durable state, hot paths and failure boundaries.

How this problem works

Design — place components and connect them on the canvas, then write your contracts.
Decide — pick the policies you would defend and note the trade-offs.
Review — run the rule-based review. Pass every check to complete the problem and add it to your review deck.

The review checks a guided model. Other valid architectures exist; it does not execute code or prove production readiness.