Fastmail is highly regarded in the systems engineering space for its speed, uptime, and strict adherence to open standards. While many large email providers abstract their scale inside opaque, proprietary cloud environments, Fastmail relies on a purpose-built, bare-metal stack designed to minimize latency and structural overhead.
1. The Core Storage Engine: Deeply Customized Cyrus IMAP
At the bedrock of Fastmail’s data layer sits Cyrus IMAP, an enterprise-grade mail server originally developed by Carnegie Mellon University. Fastmail is the primary maintainer of this open-source project, constantly tuning its internals to handle massive parallel workloads on modern hardware.
Unlike traditional mail servers that manage emails as individual files across a generic filesystem (such as Maildir) or shove them into massive relational databases, Cyrus treats mailboxes as isolated databases using specialized key-value formats like twom (Fastmail’s high-performance successor to their twoskip format). This approach grants atomic read/write behavior, preventing data corruption even when hundreds of connections access the same mailbox simultaneously.
+-------------------------------------------------------------+
| Nginx Frontend Proxy |
+-------------------------------------------------------------+
|
v (Routes via master lookup)
+-------------------------------------------------------------+
| Standalone 2U Storage Server |
| |
| +-------------------+ +-------------------+ |
| | nvmeslot (Master) | | nvmeslot (Replica)| |
| | - Cyrus Instance | | - Cyrus Instance | |
| | - ZFS Dataset | | - ZFS Dataset | |
| +-------------------+ +-------------------+ |
+-------------------------------------------------------------+
The Slot and Store Topology
To balance raw performance with high availability, Fastmail abstracts its infrastructure into structural layers:
- The Slot: Each physical storage server (typically a 2U chassis loaded with solid-state storage) is divided into up to 100 isolated environments called slots. Every slot runs a completely independent instance of the Cyrus server daemon, bound to its own internal IP address and configuration.
- The Store: A user’s logical mailbox does not live on just one machine. It maps to a “Store,” which spans a minimum of three distinct slots across separate physical servers using Cyrus’s native real-time replication framework.
Data is stored atop encrypted ZFS datasets (nvmeslots), optimizing data layouts for solid-state storage while leveraging ZFS native checksums to detect and self-heal quiet data corruption. Additionally, search indexes for active, recently delivered emails are mapped directly into a RAM filesystem (tmpfs) to provide instantaneous search execution.
2. Replication and Load Distribution
Fastmail bypasses generic block-level replication (like DRBD) or network file systems, choosing application-layer replication instead.
Asynchronous State Log Syncing
When a change occurs on the master slot (e.g., an email arrives or a flag updates), the event isn’t immediately mirrored across the network via a heavy, blocking transaction. Instead, Cyrus writes a lightweight reference to a localized replication log file detailing that something changed in mailbox X.
A standalone background daemon, sync_client, continually processes this log queue. It combines duplicate events to save bandwidth, connects to the target replica’s sync_server, and evaluates delta differences.
[Client Action]
│
▼
┌──────────────┐ Log Write ┌─────────────────┐
│ Master Slot ├────────────────────>│ Replication Log │
└──────┬───────┘ └────────┬────────┘
│ │
│ Read Deltas │ Polls
│ ▼
│ ┌─────────────────┐
│ │ sync_client │
│ └────────┬────────┘
▼ │
┌──────────────┐ Execute Deltas │
│ Replica Slot <───────────────────────────────┘
└──────────────┘
Anti-Fragile Failures
By splitting clusters into discrete slot-pairs scattered evenly across the fleet, Fastmail mitigates the “thundering herd” problem. If a physical machine hosting 50 master slots crashes, those 50 workloads fail over to 50 different companion machines across the data center, rather than overloading a single standby mirror.
3. Protocol Evolution: The Transition to JMAP
The Internet Message Access Protocol (IMAP) was designed in the 1980s. It is highly stateful, strictly sequential, and notoriously verbose. For mobile clients on unstable networks, IMAP causes significant battery drain and connection latency due to endless round-trips.
To resolve this, Fastmail designed and open-sourced JMAP (JSON Meta Application Protocol), standardized as RFC 8620 and RFC 8621. JMAP replaces legacy, plain-text IMAP commands with structured JSON data over standard HTTPS and WebSockets.
| Metric / Feature | Legacy IMAP | Modern JMAP |
| Transport Protocol | Custom TCP Stream (Port 143/993) | HTTPS / WebSockets (Port 443) |
| Data Payload Format | Custom IMAP Text Syntax | Structured JSON |
| Network Efficiency | High round-trips; sequential commands | Method batching; back-references |
| Data Scope | Mail only (Requires CalDAV/CardDAV) | Unified Mail, Contacts, and Calendars |
Stateless Batching and State Tracking
JMAP allows clients to pack multiple distinct requests—such as fetching a message list, downloading specific message headers, and checking unread counts—into a single HTTP POST request. By supporting back-references, the output of one query can be dynamically injected into the next operation within the exact same payload payload execution.
Furthermore, JMAP handles synchronization through high-efficiency state strings. Rather than parsing through thousands of individual unique identifiers (UIDs) to figure out what changed while an application was minimized, the client simply asks the server: “Here is my state token v12; send me everything that changed to bring me to the current state.” The server responds with only the precise deltas, slashing client-side processing requirements.
4. Edge Routing and The Web Frontend
When a user logs into Fastmail, their traffic hits an Nginx frontend proxy array. Nginx doesn’t rely on arbitrary session pinning; instead, it utilizes custom Fastmail Perl libraries to query an internal directory mapping table. This configuration determines exactly which physical machine and slot currently holds the master copy of that user’s store, routing the HTTP/JMAP or legacy IMAP traffic directly to that backend container.
On the client side, Fastmail’s web interface is built using their open-source Overture JS framework. Overture is built specifically around data-model state management rather than complex DOM manipulation. Because JMAP handles local modifications asynchronously, the web application executes user actions (like archiving or moving a thread) instantly on the UI thread, tracks the states locally with deep multi-level undo/redo trees, and queues the sync payloads cleanly to the backend infrastructure when network topology allows.
