Understanding Elixir processes and concurrency

Welcome to the second chapter of the “Elixir, 7 steps to start your journey” series.

In the first chapter, we talk about the Erlang Virtual Machine, the BEAM, and the characteristics that Elixir takes advantage of to develop systems that are:

  • Concurrent
  • Fault-tolerant
  • Scalable and
  • Distributed

In this note, I’ll explain what concurrency means to Elixir and Erlang and why it’s essential for building fault-tolerant systems. You’ll also find a little Elixir code example to see the advantages of concurrency in action.


Concurrency is the ability to perform two or more tasks apparently at the same time.

To understand why the word apparently is highlighted, let’s look at the following case:

A person has to complete two activities, task A and task B.

  • Starts task A, moves forward a bit, and pauses.
  • Starts task B, moves forward, pauses, and continues with task A.
  • Goes ahead with task A, pauses, and continues with task B.

And so it progresses with each one, until finishing both activities.

It is not that task A and task B are carried out at precisely the same time; instead, the person spends time on each one and interchanges between them. But these times can be so short that the change is invisible to us, so the illusion is produced that the activities are happening simultaneously.


So far, I haven’t mentioned anything about parallelism because it’s not a fundamental concept in the BEAM or for Elixir. But I remember that when I was learning to program, it took me a while to understand the difference between parallelism and concurrency, so I took advantage of this note to explain briefly.

Let’s continue with the previous example. If we now bring in another person to complete the tasks and they both work at the same time, we now achieve parallelism.

So, we could have two or more people working in parallel, each carrying out their activities concurrently. That is, the concurrency may or may not be parallel.

In Elixir, concurrency is achieved thanks to Erlang processes, which are created and managed by the BEAM.


In Elixir all code runs inside processes. And an application can have hundreds or thousands of them running concurrently.

How does it work?

When the BEAM runs on a machine, it creates a thread on each available processor by default. In this thread, there is a queue dedicated to specific tasks, and each queue has a scheduler responsible for assigning a time and a priority to the tasks.

So, on a multicore machine with two processors, you can have two threads and two schedulers, allowing you to parallelize tasks as much as possible. You can also adjust BEAM’s settings to indicate which processors to use.

As for the tasks, each one is executed in an isolated process.

It seems simple, but precisely this idea is the magic behind the scalability, distribution, and fault tolerance of a system built with Elixir.

Let’s go deep into this last concept to understand why.


The fault tolerance of a system refers to its ability to handle errors. The goal is that no failure, no matter how critical, disables or blocks the system and this is again achieved thanks to Erlang processes.

The processes are isolated elements that do not share memory and communicate through message passing.

This means that if something goes wrong in process A, process B is unaffected. It may not even know about it. The system will continue functioning normally while the fault is fixed behind the scenes. And if we add that the BEAM also provides default mechanisms for error detection and recovery, we can guarantee that the system works uninterruptedly.


If you want to explore more about how the processes work, you can check this note: Understanding Processes for Elixir Developers.

What does this look like in Elixir?

Finally, the code!

Let’s review an example of creating processes that run concurrently in Elixir. We are going to contrast it with the same exercise running sequentially.

Ready? Don’t worry if you don’t understand some of the syntax; overall, the language is very intuitive, but the goal is to witness the magic of concurrency in action.

The first step is to create the processes.


There are different ways to create processes in Elixir. As you progress, you will find more forms to do it; here, we will use the basic one: the spawn function. Let’s do it!!

We have ten records that correspond to the user’s information that we will insert into a database, but first, we want to validate that the name does not contain random characters and that the email has @.

Suppose each user validation takes a total of 2 seconds.

  1. In your favorite text editor copy the following code. Save it in a file called processes.ex
defmodule Processes do

 # We are going to use regular expressions for the name format and the
 # email
 @valid_email ~r/^([a-zA-Z0-9_\-\.\+]+)@([a-zA-Z0-9_\-\.]+)\.([a-zA-Z]{2,5})$/
 @valid_name ~r/\b([A-ZÀ-ÿ][-,a-z. ']+[ ]*)+/

# There is a list of users with a name and email.
# The function validate_users_X calls another function:
# validate_user, which checks the format of the email and prints an
# ok or error message for each record

 # This function works SEQUENTIALLY
 def validate_users_sequentially() do
   IO.puts("Validating users sequentially...")

   users = create_users()

   Enum.each(users, fn elem -> 
     validate_user(elem) end)

 # This function works CONCURRENTLY, with spawn
 def validate_users_concurrently() do
   IO.puts("Validating users concurrently...")

   users = create_users()

   Enum.each(users, fn elem ->
     spawn(fn -> validate_user(elem) end)

 def validate_user(user) do
   |> validate_email()
   |> validate_name()
   |> print_status()

 # This pauses for 2 seconds to simulate the process inserting 
 # the records into the database

 # This function receives a user, validates the format of the email and
 # add the valid_email key to the result.
def validate_email(user) do
   if Regex.match?(@valid_email, user.email) do
     Map.put(user, :valid_email, true)
     Map.put(user, :valid_email, false)

# This function receives a user, validates the format of the name and
 # add the valid_name key to the result.
 def validate_name(user) do
   if Regex.match?(@valid_name, user.name) do
     Map.put(user, :valid_name, true)
     Map.put(user, :valid_name, false)

 # This function receives a user that has already gone through  
 # validation email and name and depending on its result, prints 
 # the message corresponding to the status.
 def print_status(%{
       id: id,
       name: name,
       email: email,
       valid_email: valid_email,
       valid_name: valid_name
     }) do
   cond do
     valid_email && valid_name ->
       IO.puts("User #{id} | #{name} | #{email} ... is valid")

     valid_email && !valid_name ->
       IO.puts("User #{id} | #{name} | #{email} ... has an invalid name")

     !valid_email && valid_name ->
       IO.puts("User #{id} | #{name} | #{email} ... has an invalid email")

     !valid_email && !valid_name ->
       IO.puts("User #{id} | #{name} | #{email} ... is invalid")

 defp create_users do
     %{id: 1, name: "Melanie C.", email: "melaniec@test.com"},
     %{id: 2, name: "Victoria Beckham", email: "victoriab@testcom"},
     %{id: 3, name: "Geri Halliwell", email: "gerih@test.com"},
     %{id: 4, name: "123456788", email: "melb@test.com"},
     %{id: 5, name: "Emma Bunton", email: "emmab@test.com"},
     %{id: 6, name: "Nick Carter", email: "nickc@test.com"},
     %{id: 7, name: "Howie Dorough", email: "howie.dorough"},
     %{id: 8, name: "", email: "ajmclean@test.com"},
     %{id: 9, name: "341AN L1ttr377", email: "Brian-Littrell"},
     %{id: 10, name: "Kevin Richardson", email: "kevinr@test.com"}

2. Open a terminal, type iex and compile the file we just created.

$ iex

Erlang/OTP 25 [erts-13.1.3] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit:ns]

Interactive Elixir (1.14.0) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> c("processes.ex")

3. Once you’ve done this, call the function that validates the records sequentially. Remember that it will take a little time since each record takes 2 seconds.

iex(2)>  Processes.validate_users_sequentially

4. Now call the function that validates the records concurrently and observe the difference in times.

iex(3)>  Processes.validate_users_concurrently

It’s pretty noticeable, don’t you think? This is because in step 3, with sequential evaluation, each process has to wait for the previous one to finish. Instead, concurrent execution creates processes that run in isolation; therefore, neither depends on the former nor does any other task block it.

Imagine the difference with thousands or millions of tasks in a system!

Concurrency is the foundation for the other features we mentioned: distribution, scalability, and fault tolerance. Thanks to the BEAM, implementing it in Elixir and taking advantage of it becomes relatively easy.

Now, you know more about processes and concurrency, especially about the importance of this aspect in building highly reliable and fault-tolerant systems. Remember to practice and come back to this note when you need to.

Next Chapter

In the next note, we will talk about the libraries, frameworks, and all the resources that exist around Elixir. You will be surprised how easy and fast it is to create a project from scratch and see it working.

Documentation and Resources

Technical Adviser

Style correction

If you have questions about this story or want to go deeper, you can reach me on Twitter @loreniuxmr

See you in the next chapter!

Keep reading

Balancing Innovation and Technical Debt

Balancing Innovation and Technical Debt

Nelson Vides explores the intricate balance between innovation and technical debt.

Instant Scalability with MongooseIM and CETS

Instant Scalability with MongooseIM and CETS

Explore the enhanced scalability features of MongooseIM 6.2.1 with its improved CETS in-memory storage backend, offering flexible solutions for managing unpredictable XMPP server traffic.

The Golden Age of Data Transformation in Healthcare

The Golden Age of Data Transformation in Healthcare

In today's healthcare industry, data is the lifeline driving advancements and improving patient outcomes. However, the true value of this data is realized only when it is accessible and interoperable across systems.