How do we process 100’s of temp emails per second?

At nada we like to give users great UX, one of the features we wanted to have from the get go is the ability of anyone to just invent an email address with @

ending or any other of our domains, without first visiting our site.

So when someone goes to register a new account on some third party site, they don’t have to first go to

but instead go directly to the third party site and enter as email say ‘[email protected]’.

This looks like an easy feature to support but actually it complicates things quite a bit. We use

email server to process our incoming emails. And for Haraka, Lots of emails are not a problem (according to their benchmarks, it can easily handle 5K emails per sec on a standard laptop). However, for our databases (mongo), processing 100’s of emails per sec is too much, it would make the site sluggish and queries slow.

We know which inboxes are in use when users first check the up on our site, and can raise a flag in the DB saying this box is active for the next say 7 days. But how can we know the same for inboxes the user just invented a couple of seconds ago, on a different site?

We assume an incoming mail for an unseen before inbox can be such a use case, The solution is to keep all incoming messages for an hour in memory and assume someone who just registered on some third party site will go to nada to check his incoming messages.

We don’t process any of these messages, no indexes are written to disk, and only in the event the user actually goes to check the inbox on our

site, we copy the waiting messages to the main DB and clear the memory for that inbox.

Statistically less than 1% of messages get opened this way. So it’s a huge waste of memory, luckily we have lots of it (128GB machine) and can handle millions of emails waiting in memory for this one hour.

Currently the amount of emails that wait there can go all the way up to ~ 500K, but as the site grows and inboxes get older they keep getting more and more spam we expect this number to raise.

The are other algorithms we can deploy to handle such a case, when memory will reach it’s limit, but right now for the few coming months, memory should suffice.

When implementing this feature I had doubts about it’s usability, but after using the site for a long time and getting used to this feature, I can say it’s one of the best examples of simple intuitive use case that looks trivial but is irreplaceable.