<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 11, 2015 at 7:48 PM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'd probably use the file system, then ets or dets and "roll my own" first.</blockquote></div><br>To much extent, this is what WhatsApp is doing according to what I've been able to dissect out of their talks. They use mnesia for storing meta-data, but they use an UFS2 file system on FreeBSD to store the majority of data and just pick it off of the disk whenever they need it. The other trick they use is to use the clients to store the majority of data and only use the servers as a temporary transient store until the client comes back up and requests its missing data.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Were I to start, I'd definitely do the API modularity split as well, but I'd probably pick postgresql as a backing store over mnesia, perhaps with mnesia as an in-memory cache for active users. The assumption is user data is not changing that often, and postgresql have the added value of being a system I *know* how to operate and handle. There is much to be said for picking technology which is tried and proven and you know how to operate.</div><div class="gmail_extra"><br></div><div class="gmail_extra">A possible switch is Riak for the UFS2 store, but it does require the ability to "append" to an object in Riak. Otherwise it is kind of moot to load data, add a couple of bytes and store the object back again. Perhaps this can be done by "chaining" documents in Riak with content addressing.<br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">J.</div>
</div></div>