You are making a very classic mistake here – you are trying to find a simple formula.

There is no simple formula though.

The actor model (Erlang processes) is about being able to model runtime entities. Which entities, how many, and when are they spawned depends on your business requirements.

Actors are just one more tool in your belt.

This article might help a little bit: The Erlangelist - To spawn, or not to spawn?

But again, don’t expect a simple formula.

That’s part of the entire answer – and here the partial answer is “yes”.

But there’s also the aspect of “I want to control access to a resource” (you already mentioned locking) and “I want to make sure this entity receives messages only one by one, sequentially” (what GenServers do).

Actors in Elixir generally map to runtime subcomponents of the system, not business entities. So for example when using phoenix channels or live view every connected page is an actor that manages messages in and data out, but then the business logic processing on that data favors functional data patterns.

Well, roughly – yes, that’s one factor.

But there’s more to it. So imagine your app is for example about reserving hours to doctors. And in your controller you have to consult a 3rd party API (for example Microsoft Calendar).

• If you want to give people immediate confirmation or rejection, you do the 3rd party API call (a network request) inside your controller function without spawning a process, so your customers will have to wait in the browser until that request completes.
• If you opt for customers to never wait you will spawn this 3rd party network API call in a new process and immediately return something to the customers like “We have requested reservation of the hours of this doctor. You should receive an email within a few minutes telling you if the hours are free.”

As you can see, this is not about the technical capabilities, this is about what the business wants.

1. Processes (the actors) are used plenty in every Phoenix project, it was just made invisible to you and for your convenience. For example: the DB repo is basically a pool of connections but each connection is held up by a single process.
2. Each request is in a new process. If you have 50 currently active requests, you have 50 extra processes. If you have 2000 currently active requests then you have 2000 extra processes.
3. Libraries like Oban (for background jobs) use processes pervasively.

Frameworks like Phoenix already make use of processes. From then on it’s on you if you want to use extra processes.

As others have said, don’t use processes to model logic. Use processes to model separate runtime entities (like a task that needs to download stuff from 3rd party API, for example).

No, they are used for other purposes as well. See above.

It’s used all the time. Elixir code can’t run outside of a process. Even just booting up a vanilla REPL ($ iex) spawns 60 processes.

I’m no expert on the topic and I would search this forum for discussion about it as there is a bunch.

The TL;DR is model your business domain in pure functions, then run those functions in processes. Many of your examples are correct, like yes, a chatroom would run inside its own process. If you’re using LiveView in Phoenix, every user connection is a process.