That's a tiny database size, would fit entirely into memory, but according to the docs: "Because MongoDB uses a thread per connection model, each database connection also will need up to 1MB of RAM, whether active or idle." So how big is your pool? I think 4GB is probably an order of magnitude more than you need right now, but with 1k concurrent users, it sounds like the size of your db is going to grow significantly? Also depends on how you're able to utilize index inserts, which will depend on the sequentiality of your index ids. How much RAM do you have now? How much is Mongo using? How much has it grown as your app/db size/indexes have grown? What's your performance like now?

In my mind, one of the greatest benefits of RESTful APIs is the discoverability provided by the URI. To that end, I always prefer to put API version information in the URL itself. This dramatically reduced the amount of go-round between yourself and outside developers when troubleshooting any issues with the API, or their implementation on the client end. If API version is stored in headers, this is less clear and can lead to hidden issues. Is this truly REST? Enh, you could argue not, that the URI pointing to the resource changes with the version. I find that letting the REST-at-all-costs mentality guide the design of my APIs only hinders the usability. Very few people actually design fully REST-compliant software, so we're all trying to find out which deviations improve upon the pattern in the real world. Mandatory versions in the URL, in my opinion, is one of the better deviations to make. As always when discussion REST API design, I must plug this short and easy to read PDF by Apigee: https://pages.apigee.com/rs/apigee/images/api-design-ebook-2012-03.pdf . This is some of the best advice you'll get on the subject, and it only takes about 30 minutes to read.

Elixir is quite new (all things considered), so its list of success stories is small. This list claims to have many companies using it in production, and if the list is true, it's nice, but with no documentation or citing, it's functionally useless. Puppet Labs on that list has advertised that they are hiring Elixir devs, though, so that one is correct. Erlang has more representation . As @Jan mentioned, many companies run RabbitMQ as critical infrastructure, and RabbitMQ is probably the most widely used Erlang program. WhatsApp is very vocal about how Erlang let them scale to ludicrous heights with a very small team and small infrastrucutre. They managed to get 3 Million simultaneous connections on a single machine (granted, I think it had 48 cores and 128GB of RAM or something). Apparently, FaceBook also uses it to run its backend for Messenger , thought I think they've since moved to C++. All of these products have the same base criteria: soft-realitime, very high availability, very high concurrency, small amounts of data exchanged. This is the area where Erlang/Elixir/OTP really shine. The Phoenix web framework makes Websocket support trivial, and it was recently tested up to 2 million concurrent connections . So if your application has that type of profile, Elixir should be given a hard look. You can do a lot more with much less hardware, achieve huge amounts of uptime and reliability, and the language is a pleasure to work with.

I've used NPM's 'acl' package before, and it's feature-ful while keeping a very simple API. It also provides a simple Middleware for Express, if that's what you're using, but it's easy enough to slip it into most other frameworks. I set the role on the user model, and then do acl.addUserRoles(user.id, user.role) . If you have more complicated requirements for multiple roles, it would be easy enough to loop over a roles array. If using Express, you will need a session for every user, and it must contain a userId parameter.

Which is very true when talking about new technology vs. old. It's a more nuanced conversation when it comes to two "good-enough" maturity projects. Spring Boot vs. Dropwizard. C# vs. Java. CentOS vs. Ubuntu. AWS vs. Azure. Puppet vs. Ansible. Express vs. Koa. MariaDB vs. PostgreSQL Any of those choices above could be the correct answer, and in most cases, you could completely swap one for the other, and the project would be just as much a success (the feature sets largely overlap). In this case, it's about if edge-case features matter to you, or how experienced your team is on a given platform. In the case where neither matter (you're equally inexperienced or experienced, the feature-parity fits your requirements, and the communities are equally engaged), it mostly comes down to some "gut feeling" by your most senior devs.

@Jan, Elixir is language that feels very similar to Ruby, but compiles down to Erlang bytecode. It's functional and has immutable variables. It uses the actor-messenger pattern and very lightweight threads for concurrency. It runs on top of the OTP framework, which is implemented in Erlang, and provides the huge amount of concurrency Erlang systems are known for. I have loved learning the language, and it has caused me to learn functional programming at a much more fundamental level than I previously had.

When evaluating senior level and up developers, I look for a mandatory quality -- opinionated but open. You need to be opinionated in choosing your technology, and often this falls down to "I am most comfortable with and have the most experience with X". In the current technology ecosystem, there are thousands of competing language/framework/database/ops choices. Many will have overlapping pros/cons, and you may never reach the corner cases that distinguish them. When that is the case, experience will give you a gut feeling, and you should stick with this feeling. Additionally, you should usually give preference to the tools you have used before as that will reduce implementation time and trouble, as well as increase efficiency. That's being opinionated. However, you must always be able to back your reasoning with facts. "X is good for this project because ." If you can't do that, then your opinion is uninformed and not useful. Additionally, you must always be open to there being a Y that is categorically better than X for the task. And if someone brings that to your attention, and has a good rationale, and the cost and time of implementing Y is within the projects budgets, you must be open to using Y. That's being open. So when someone questions why I use X, I do not hesitate to say it's because I prefer X, and I think X is good for this project because of factors A, B, and C. If someone says "Y would be better than X here", I'll listen to their justification and weigh the cost of learning Y. If it's convincing, I'll give Y a shot (after doing my due diligence). Having a large toolbox at your disposal is invaluable, but there's simply too many tools in tech now to be able to learn them all. Pick ones you like using (or at least are the least hateful of the choices you have -- Ansible, looking at you), and be open to learning something new if there's a very compelling reason to do so.

I've enjoyed working with Elixir and the Phoenix framework to create APIs and handle websockets communications. I find the Websockets abstraction to be very clean, and pattern-matching the message itself is both intuitive and easy to reason about. Ecto, the database-abstraction, uses a DSL that feels almost like writing SQL, both DDL and DML. Phoenix scales incredibly well -- a single (albeit large) server can handle millions of simultaneous websocket connections. Adding more servers to a cluster is also trivial, and built into the underlying OTP framework. The ecosystem is solid -- there's one prescribed test library, one documenting system, a release manager in Exrm, package manager in Hex, and build system in Mix. I really enjoy writing in Elixir, in a way I haven't felt since discovering PHP in 2001. Operations wise, I find Ansible to be super easy to use, and very quick to pick up. It handles most of my mundane server operations at scale. I've not found a need personally to add Chef or Puppet in concert with it. I like the premise and promise of Docker -- all the benefits of Vagrant without the myriad problems we ran into with VirtualBox and Vagrant. I've toyed with it and like it, but do not use it for production use yet. I do think Ansible + Docker will make a mighty fine pair in the coming year or two. Postgres has been my go-to database for about 5 years. With the recent addition of the jsonb type, we have much of the power of Mongo, but with the ability to to add relational data in the same storage mechanism. It's super stable, highly performant, and scales well (though the tooling around the scaling is a little lacking if you're looking for anything beyond read-slaves and/or partitioning, such as multi-master). With extensions such as PostGIS, and the ability to write stored procs in languages other than PL/SQL (python, even JS), it feels both extensible and modern. The main drawback I can think of is that the best-of-breed GUI is Navicat by leaps and bounds, and it's expensive and I hate the licensing setup(per OS, and per DBMS). Frontendishly, I will admit I haven't done much of substance in a while. I enjoyed the power of Angular 1.X but it was definitely still maturing during my usage in 2013. I can see why people would pick React/Flux, and I've played with toy apps using that design pattern and library, but I can't speak on using it to build anything substantial. I like the idea of the one-way data flows in terms of reasoning about my dataflows, but you do need what seems like a lot more boilerplate to accomplish the same tasks as Angular. It's a tradeoff, but I couldn't tell you if it's worth it or not. My gut instinct says yes.