Sharing My Side Project: TempMail3 – A Lightweight Temporary Email Service

Hey everyone, I recently launched a side project 👉 tempmail3.com.
Instead of pushing a product, I want to dive into the technical side and share how it works under the hood. Maybe it can help other devs building similar tools.

Why Build a Temporary Email Service?

During development, I often run into situations where I need:

• To repeatedly register accounts for testing login/signup flows
• To subscribe to services without spamming my main inbox
• To verify email notifications

Existing solutions often fall short:

• Pages are cluttered with ads, making them slow and frustrating
• Some require sign-ups, which defeats the purpose of “temporary”
• Email delivery can be delayed, slowing down testing

So I decided to build something lightweight, fast, and anonymous.

System Architecture

The core logic of TempMail3 is simple:

1. Generate a temporary address as soon as the user opens the page
2. Receive and forward emails via a lightweight backend mail server
3. Push emails in real time to the frontend using WebSocket
4. Auto-destroy expired addresses and emails to keep it lightweight and private

Architecture diagram (simplified):

External Mail → Node.js SMTP Receiver → Redis (short-term storage) → WebSocket → Frontend UI

Technical Details

1. Email Reception

• Node.js runs an SMTP server to receive emails
• Incoming emails are parsed into JSON and stored in Redis

2. Short-Term Storage

• Redis handles caching with TTL to automatically expire old emails
• Each temporary email and its content has a defined lifespan (default: 10 minutes)

3. Real-Time Delivery

• Frontend maintains a WebSocket connection with the backend
• When Redis receives a new email, it’s immediately pushed to the correct client
• This avoids constant polling and improves user experience

4. Frontend UI

• Built with React + Tailwind, fully client-side rendered
• Generates a random email instantly on page load
• Minimal, ad-free, “ready-to-use” experience

Technical Trade-Offs

• No persistent database: Temporary emails are meant to be short-lived, so I skipped long-term storage, which also reduces security risks.
• Redis over SQL: Redis TTL makes automatic cleanup simple and lightweight.
• WebSocket over polling: Cuts down request overhead and ensures instant updates.

Lessons Learned

1. Constraints are more important than features
   Temporary emails are defined by their short lifespan. Adding too many features would dilute the core experience.

2. Tech choices define complexity
   Starting with MySQL would have complicated cleanup logic. Redis + TTL keeps everything simple.

3. Shipping beats perfection
   The MVP took just two weeks. Only after launch did I spot real bottlenecks—mostly around email push speed.

Next Steps

• Browser extension: One-click temporary email generation
• Developer API: For integrating into automated testing workflows
• Flexible lifespans: Options like 30 minutes or 1 hour

Final Thoughts

If you’re building small tools and want a reference implementation, check out tempmail3.com.
I’d also love to hear from you:

👉 When do you usually use temporary emails?
👉 If there were an API, what data structure would make it easiest to integrate?