This article is the final one of the series about distributed reactive apps in Erlang/Elixir. In the first article you will find the theoretical basis of reactive architecture. The second one illustrates the main templates and mechanisms of building such systems.
Today we will address the questions of code base development and projects development in general.
In the previous article we have addressed the theoretical basics or reactive architecture. Now it’s time to talk about data flows, ways of implementing reactive Erlang/Elixir systems, and message exchange patterns included in them:
These days, the world is moving fast. Progress constantly creates new technological challenges. Information systems architecture should be flexible enough to respond to new requirements and evolve. In this article, we are going to talk about event-driven architecture, concurrency, parallelism, asynchrony, and how to live in peace with all that in Erlang.
Today we are going to talk about logs, quantitative metrics, and how to observe them in order to increase the team reaction rate and reduce the system waiting time in case of an incident.
Erlang/OTP as a framework and ideology of developing distributed systems provides us with regulated approaches to development, proper tools, and implementation of standard components. Let’s assume that we have exploited OTP’s potential and have gone all the way from prototype to production. Our Erlang project feels perfectly fine on production servers. The code base is constantly developing, new requirements are emerging alongside with functionality, new people are joining the team. Everything is, like…fine? However, from time to time something might go wrong and any technical issues combined with human factor lead to crash.
As you just can’t have all the bases covered and foresee all the potential dangers of failures and problems, then you have to reduce the system waiting time via proper management and software solutions.
Even school students know that there are different number systems. As well, they are aware of the fact that not every finite decimal fraction equals to its finite binary representation. However, not many of us realize that due to this fact all operations with floats and doubles are never precise enough.