Message read and write throughput scales linearly as more nodes added.

Underlying components – Cassandra and Blob Stores also can scale linearly to thousands of nodes.


ElasticInbox itself was designed with “share-nothing” architecture in mind where every node is independent. This means no single point of failure.

Cassandra and Blob Stores are also decentralized.

Fault Tolerant

ElasticInbox stores information in Cassandra and Blob store. Both technologies provide automatic replication to multiple nodes. Both support replication across multiple data centers. Failed nodes, whether it’s ElasticInbox, Cassandra or Blob store, can be replaced with no downtime.


Diagram below depicts sample architecture:

ElasticInbox Architecture

Why ElasticInbox?

Typical email delivery process involves a number of components:

  • Mail User Agent (MUA) – e.g. Mozilla Thunderbird, Microsoft Outlook
  • Mail Transfer Agent (MTA) – e.g. Postfix, Exim
  • Mail Delivey Agent (MDA) – ElasticInbox
  • IMAP, POP3, and other interfaces to access mail

MDA is responsible for storing messages. Most of the existing MDAs (or sometimes MTAs) store messages only on the locally mounted filesystem which is sufficient when you have few thousands of accounts. However, when you need to serve millions of accounts, local filesystem is not an option.


ElasticInbox MDA can serve millions of accounts and scale linearly – no bottlenecks, no single point of failure, multiple replicas provide fault tolerance. This is perfect solution if you run on the private or public cloud – just add more nodes as you grow. Messages are delivered over the standard LMTP protocol.

In addition to MDA, ElasticInbox also supports RESTful interface for managing, retrieving and storing messages. It provides an easy way for building web services (such as webmail, admin panel, etc.) on top of ElasticInbox. See some examples below.

See roadmap for the full list of planned features.