A webinar talk exploring how concurrency works inside the BEAM virtual machine and Erlang runtime system, with a focus on understanding real capacity limits. Using an e-commerce pricing server as a running example, the talk explains how BEAM schedulers, run queues, process mailboxes, and memory interact to create system saturation. It covers three types of saturation signals (localized bottleneck, system-wide CPU saturation, and memory/queue compounding), how to observe them using tools like Observer and Recon, and strategies to address each — including worker pools, back pressure, caching, and dropping stale requests. The core message: BEAM makes concurrency cheap but not free, and sustainable systems require understanding and respecting capacity limits.

19m watch time

Sort: