Most of the jobs I accept are to fix in some way legacy code. Most of them are regarding to Erlang/OTP. I always find the same pattern. The people who wrote originally the code had no idea about the platform where they were writing code and neither they take advantage of its strengths nor they avoid its weaknesses.

For me, use stateless processing for Erlang/OTP based on database is pretty similar to try to nail a screw with a hammer. You can but the result is not as you can expect.

The first point to start to use a language and platform is realise what are the best practices and good designs to use it. What are the way to build the ecosystem and perform the releases and of course, the better way to go to production.

For example, if you wrote a code accepting requests from HTTP endpoint, do a processing retrieving information from the database and even generates some background processing or updates to be in use for different users making requests. The good way in other platforms is use a database backend to support everything of this and create a system completely state-less, fire-and-forget. For Erlang that’s not the point.

Erlang can accept a huge number of requests and burst whatever database so, the access to the database should be limited and the use of in-memory cache and keep status for users is a must in most of the cases.

The design for specific solutions are not the same if you change one element. For example, if you are using an SQL database and you want to use a cache layer in the middle (memcache or redis) is a good point and very useful in different designs. But if you have a NoSQL maybe that’s not the point because most of the NoSQL databases works as a cache themselves so makes no sense.

In the same way don’t take advantage of the actors and the possibility to create as many processes as you need keeping the state of them in memory is not take advantage of one of the most important feature in the BEAM (the Erlang Virtual Machine) platform.

It’s important to point that if you want to change of language or platform and you have no idea about how works exactly that language or platform it’s better to get training first from other colleagues or companies specialised in training and in that technology to avoid to waste too much time going in a wrong direction.

Finally and to introduce the way so many Erlang projects works. A good design to use Erlang/OTP is to create an element where you have to connect so many clients (hundred of thousands or even millions of them) and keeping the state of each of them in memory across the cluster to speed up the actions to be performed by the users. That’s the way some projects like ejabberd or MongooseIM works.

And even control the limited resources to speed up the way you can use them. That’s the way Riak, Couchbase, RabbitMQ or VerneMQ works. They keep as many information in memory as they can limiting the writes to hard-disk.

So, if you want to use Erlang/BEAM (and actually this could applies to another language/platform as well), read first where it was used and how before to avoid to write code you’ll have to change in a future because the design was not correct.