A project usually has a single gamble only. Doing something you’ve never done before or has high risk/reward is a gamble. Picking a new programming language is a gamble. Using a new framework is a gamble. Using some new way to deploy the application is a gamble. Control for risk by knowing where you have gambled and what is the stable part of the software. Be prepared to re-roll (mulligan) should the gamble come out unfavorably.

Jesper L. Anderson on Medium

Jesper, who freaking tests distributed databases and other systems, has much more specific advice on how you should build your apps. He has good advice. Read it. (I promise not to make you write Erlang)