Klarna (the European payment processor) and WhatsApp architectures are built on Mnesia. Mnesia is Erlang's built-in distributed database. Due to its age it has a few bad corner cases, that could be fixed if it just had a better backend (the front-end API is nice, well designed, supports transactions, is built-in to the lanauge).

So this effort brought in the ability to have a better backend, and make Mnesia a better option as a general purpose distributed database.

Here is an talk on how WhatsApp uses Mnesia:

Erlang Factory 2014 - That's 'Billion' with a 'B': Scaling to the Next Level at WhatsApp

https://www.youtube.com/watch?v=c12cYAUTXXs

Here is an example of using Mnesia:

https://en.wikibooks.org/wiki/Erlang_Programming/Using_mnesi...

scurvy

Raise your hand if you're ever actually run mnesia on a busy server in a distributed system. OK, show of hands of how many people will do that again? Thought so.

mnesia should not be in the OTP. Not by a longshot.

I love Erlang. I hate mnesia.

derefr

I think people are trying to use mnesia for things it wasn't made for. mnesia basically has exactly one purpose:

• in a 1:1 master:hot-spare setup,

• where the nodes contain their own data in process-memory-space rather than relying on a separate "database" node,

• and you need to be able to fail-over to the hot-spare and promote it to master, without business logic being aware of this,

• and your system has time tolerances allowing you to manually fix the old master and bring it up as the new hot-spare,

then mnesia is perfect.

You know what system I'm describing?

Call switching!

You know what system I'm not describing?

Most things!

lostcolony

Actually, a lot of internal business style applications fit Mnesia's model too (if you're hosting them in a single datacenter). While it means you'll need to manually deal with netsplits (or write your own code to address them, or try to borrow https://github.com/uwiger/unsplit), if you're hosting it internally on your own servers, that might be a rare enough event (and with sufficiently minimal likelihood/consequence of things going down, coming back up, etc, such as to introduce problematic inconsistencies rather than downtime/ignorable inconsistencies in the event of major network/system thrashing) as to be worth it for certain things.

Something, like, say, file processing. You have a watch directory, you want to be able to process everything that lands in that directory in a scalable manner, but don't want to re-process the same thing (but it's okay if you do, just inefficient). Mnesia is probably fine to keep tabs of what you've processed already; in the event of a netsplit you can just let all sides of it keep going, until you get around to fixing the cluster. Your inconsistencies just lead to inefficiencies, rather than real data loss, and you have a clear path to fixing them (just dump the data on the partitioned nodes, and rejoin them to the cluster). As such, you have a more resilient, scalable system than you would if you just used a centralized database, while not having to configure and manage a separate DB.

That said, I like the idea of being able to swap Mnesia out for something a little less warty, if it's pretty seamless in operation.