Why We Never Store Your Data: A Technical Deep Dive into 10 Minute Mail's Memory-Only Architecture

Published January 6, 2026 by Devon Hillard, Founder of 10 Minute Mail

When I created 10 Minute Mail on November 3, 2006, I made a deliberate architectural decision that has defined our service for over 18 years: we would never use a database. Not because we could not afford one, not because it was easier, but because it was the only way to guarantee true privacy.

In an era where companies collect, store, and monetize user data, 10 Minute Mail takes the opposite approach. We cannot share your data with anyone because we do not have it. We cannot be compelled to hand over email records because they do not exist. This is not a policy decision - it is an architectural one.

The Architecture: Memory-Only by Design

Most web applications follow a familiar pattern: user data goes into a database, gets backed up, replicated, and persists indefinitely. Our architecture is fundamentally different.

How Traditional Email Services Work

A typical email service stores your messages in a database - usually something like PostgreSQL, MySQL, or MongoDB. Your emails are written to disk, backed up regularly, and often replicated across multiple servers for redundancy. Even "deleted" emails often remain in backup systems for months or years.

How 10 Minute Mail Works

10 Minute Mail uses a ConcurrentHashMap - an in-memory data structure - as our sole data store. Think of it like a sophisticated dictionary that exists only in the computer's RAM (working memory), not on any hard drive or SSD.

Here is a simplified view of how it works:

// Conceptual representation of our architecture
// Sessions live ONLY in memory - never written to disk

Map<String, UserSession> activeSessions = new ConcurrentHashMap<>();

// When you visit 10MinuteMail:
UserSession session = new UserSession();
session.emailAddress = generateUniqueAddress();
session.emails = new ArrayList<>();  // Empty inbox
session.expiresAt = now() + 10 minutes;
activeSessions.put(session.id, session);

// When your session expires:
activeSessions.remove(session.id);
// That is it. The data is gone. Forever.

Each user session contains your temporary email address and any emails you have received, stored in a thread-safe list. When your 10-minute timer expires, the entire session - including all emails - is simply removed from memory. There is no "delete" operation hitting a database, no cleanup job running later. The data ceases to exist.

What This Architecture Means for Your Privacy

1. Zero Data Retention - Literally Impossible to Recover

When your session expires, your data is not "marked as deleted" or "moved to trash." It is deallocated from RAM. Even with physical access to our servers, there is nothing to recover. The bits that held your emails are immediately available to be overwritten by new data.

Compare this to traditional services where "deleted" often means "flagged as deleted but still recoverable for 30-90 days."

2. No Regulatory Compliance Burden

GDPR, CCPA, and other privacy regulations require companies to manage stored personal data responsibly. They mandate data retention policies, right-to-deletion requests, and data portability.

We sidestep these complexities entirely. You cannot violate data retention requirements when you do not retain data. There is no personal data to export, delete, or manage because it never persisted in the first place.

3. Cannot Leak What Is Not Persisted

Data breaches happen when attackers access stored data. Our architecture provides an unusual form of protection: even if someone gained complete access to our servers, they would only see currently active sessions. All historical data - the millions of sessions from the past 19+ years - simply does not exist anywhere.

There is no database dump to steal. No backup tapes to intercept. No cloud storage bucket to misconfigure.

4. Tamper-Proof Privacy

With filesystem access to most email services, an attacker could read database files, log files, or backup archives. On our servers, filesystem access yields nothing useful - the data lives only in RAM, and reading arbitrary memory from a running Java application requires sophisticated attacks that would likely crash the service before yielding useful data.

5. Architectural Simplicity

No database means no database administration, no schema migrations, no backup management, no replication lag, and no database-related security vulnerabilities. Our attack surface is dramatically smaller than a traditional web application.

Technical Deep Dive: The Components

Session Management

Our SessionManager maintains the central ConcurrentHashMap. This data structure is specifically designed for high-concurrency access - hundreds of users can create, read, and expire sessions simultaneously without conflicts.

// Session structure (simplified)
class UserSession {
    String id;              // Unique session identifier
    String emailAddress;    // Your temporary email
    List<Email> inbox;      // Received emails (max 100)
    Instant expiresAt;      // When this session dies
    Instant lastActivity;   // For extension requests
}

Email Reception

We use SubEtha SMTP, an embedded SMTP server written in Java. When an email arrives:

1. SubEtha receives the email over the network
2. We parse it and extract the recipient address
3. We look up the corresponding session in our HashMap
4. If found, we add the email to that session's inbox list
5. If not found (expired session), the email is simply discarded

The email never touches a disk. It goes from network buffer to memory to your browser.

Inbox Limits

Each session can hold a maximum of 100 emails. If you receive more, the oldest emails are automatically removed (FIFO - First In, First Out). This is not a limitation but a feature: it prevents any single session from consuming excessive memory and ensures resources are fairly distributed.

Modern Java Performance

We run on Java 21 with virtual threads, allowing us to handle many concurrent email deliveries efficiently. Virtual threads are lightweight - we can process thousands of incoming emails simultaneously without the overhead of traditional thread pools.

Why Not Just Use a Database with Auto-Delete?

A reasonable question: could we achieve similar privacy with a database that automatically purges old records? Technically yes, but with significant caveats:

• Backup vulnerability: Databases are typically backed up. Even with auto-delete, your emails might exist in backup archives.
• Write-ahead logs: Most databases write transactions to log files before committing. Your emails would exist on disk, at least temporarily.
• Replication: For reliability, databases replicate data to multiple servers. More copies mean more potential leak points.
• Recovery features: Database "point in time recovery" could potentially resurrect deleted data.
• Complexity: More components mean more potential security vulnerabilities.

Our memory-only approach eliminates all of these concerns. It is privacy by architecture, not by policy.

The Intentional Choice

I want to be clear: this architecture is a deliberate choice, not a limitation. Modern cloud infrastructure makes databases trivially easy to deploy. We could use AWS RDS, Google Cloud SQL, or any number of managed database services.

We choose not to.

For 19+ years, through multiple complete rewrites of the application (from JBoss Seam to DeltaSpike to Spring Boot), we have maintained this core architectural principle. Technologies change; our commitment to your privacy does not.

What About Server Restarts?

Here is the trade-off we accept: if our server restarts, all active sessions are lost. Users would need to create new temporary email addresses.

We consider this an acceptable trade-off. Your privacy is more important than session continuity. And honestly, how often do you need a temporary email address to survive a server restart? The typical use case - signing up for a website, verifying an account, receiving a confirmation - completes well within the 10-minute window.

Frequently Asked Questions

Can you retrieve an email from an expired session?

No. Once a session expires, the data is gone. We cannot retrieve it, law enforcement cannot subpoena it, hackers cannot steal it. It no longer exists.

Do you keep any logs of email content?

No. We log operational metrics (server health, error rates, aggregate traffic) but never email content or even email metadata like sender addresses or subject lines.

What if someone sends me something important and my session expires?

This is by design. 10 Minute Mail is for temporary, disposable communication. For important emails, use a permanent email address. The temporary nature is a feature, not a bug.

Is this architecture scalable?

Yes. ConcurrentHashMap is highly optimized for concurrent access. We have served millions of users with this architecture. The memory footprint is manageable because sessions naturally expire and free up resources.

Try It Yourself

Experience the difference that true privacy-by-design makes. When you use 10 Minute Mail, you are not trusting us with your data - you are trusting our architecture to make data retention impossible.

No account required. No personal information collected. No data retained after your session ends.

Get Your Temporary Email Now

Have questions about our architecture or privacy practices? Feel free to reach out. Unlike your emails, our commitment to privacy is permanent.

Devon Hillard is the founder of 10 Minute Mail, which he created in November 2006. He has been building privacy-focused tools for nearly two decades and remains committed to the principle that the best way to protect user data is to never store it in the first place.