{"id":30785,"date":"2019-10-31T21:37:25","date_gmt":"2019-10-31T18:37:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/stroitelnye-bloki-raspredelennyh-prilozhenij-nulevoe-priblizhenie\/"},"modified":"2019-10-31T21:37:25","modified_gmt":"2019-10-31T18:37:25","slug":"stroitelnye-bloki-raspredelennyh-prilozhenij-nulevoe-priblizhenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/stroitelnye-bloki-raspredelennyh-prilozhenij-nulevoe-priblizhenie","title":{"rendered":"Building blocks of distributed applications. Zero approximation","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Building<\/p>\n

<\/p>\n

The world is constantly changing. Progress creates new technological challenges. In accordance with the changing demands, the architecture of information systems must evolve. Today, we will discuss event-driven architecture, concurrency, parallelism, and asynchrony, as well as how to coexist peacefully with all of this in Erlang.<\/p>\n

<\/a><\/noindex><\/p>\n

Introduction<\/h2>\n

<\/p>\n

Depending on the size of the designed system and its requirements, we developers choose a way to exchange information within the system. In most cases, a broker-based approach, for example using RabbitMQ or Kafka, is a practical option for organizing service interactions. However, sometimes the event stream, SLA, and level of system control are such that off-the-shelf messaging doesn\u2019t suit our needs. Of course, we can complicate the system a bit by taking on the responsibility for the transport layer and cluster formation, for example using ZeroMQ or nanomsg. But if the system has sufficient bandwidth and capabilities of a standard Erlang cluster, the question of adding an additional entity requires thorough examination and economic justification.<\/p>\n

<\/p>\n

The topic of reactive distributed applications is quite broad. To fit the format of this article, today we will focus only on homogeneous environments built on Erlang\/Elixir. The Erlang\/OTP ecosystem allows for the implementation of a reactive architecture with minimal labor costs. However, we will need a messaging layer. <\/p>\n

<\/p>\n

Theoretical Basis<\/h2>\n

<\/p>\n

The design process begins with defining goals and constraints. The primary goal does not lie in development for the sake of development. We need to create a secure and scalable tool that can support and, most importantly, develop modern applications at various levels: starting from single-server applications that serve a small audience, which can later evolve into clusters of 50-60 nodes, to federations of clusters. Thus, the main goal is to maximize profits by reducing the cost of development and ownership of the resulting system.<\/p>\n

<\/p>\n

We will outline 4 main requirements for the final system:<\/p>\n

<\/p>\n