Let's take the following for-granted: Doing security, Privacy and Scalability last is a bad idea.
But you do not engineer a system that is supposed to have at the most a thousand users the same way you engineer a system that might have millions of them. That said, when you are constructing a Framework the assumptions you make on the use cases and number of users are at best a wild guess. Developers are like that, crazy. Even if you get a lot of really smart people in a room there is a very good chance you'll get it wrong. Enough to look at the IPV4 address space... but if IPV6 addresses were implemented at the beginning of the Internet the network overhead might have been unacceptable. Maybe the whole thing would not have worked. So one of the major issues when designing a new system that does not have a very strict, limited and stable use case, is writing only the code of the scalability you need while deferring that of future needs while having a very strong notion of why there are no strict impediments for it to scale later.
We will look at some of the design decisions at the heart of U.C. Engine our Realtime Collaboration Framework, and see why choosing a documented oriented store as a persistence layer is a good idea when there are some assumptions that are too early to be made. Why and how it allows us to defer some of the scalability issues. We'll look specifically at MongoDB that we chose it side by side with Mnesia. We shall examine the issue of impedance mismatch between records and documents. And to get really down to the nitty gritty stuff we will also take a hard look at the current state of MongoDB libraries in Erlang. Why we chose emongo, what we learnt from this about the state of libraries in Erlang and how this effects doing a larger web oriented open source project.
Sign in to add slides, notes or videos to this session