A concurrency model defines how a language represents simultaneous computation and coordinates independent work. In Erlang and BEAM, it is designed around availability: lengthy tasks should not block unrelated requests, background jobs, or live software updates. section 1.1.1 section 5.1
BEAM processes are lightweight concurrent threads of execution managed by the virtual machine rather than directly by the operating system. They may run in parallel when CPU cores are available, while isolation limits the effect of failures. section 5.1
The model connects concurrency to production behavior:
- Run work in separate processes so one lengthy request does not cause request queues to grow indefinitely or make the system unresponsive. section 5.1
- Isolate processes so an unhandled exception can be localized instead of corrupting unrelated tasks or crashing the entire server. section 5.1
- Schedule many lightweight processes across VM-managed schedulers, with each process receiving an execution time slot before preemption. section 5.1
Fine-grained game concurrency
An online multiplayer game can use at least one process per participating player and per game session. This granularity improves responsiveness, enables vertical scalability, and increases fault tolerance more directly than assigning many activities to a small number of microservice instances. section 1.1.5
Visualize BEAM as one operating-system process containing a few scheduler threads that coordinate a much larger population of VM-managed processes. section 5.1
