Using OTP in Your Phoenix App
summary
Shows that moving large, shared game state out of per-request memory and into GenServer encapsulation cuts repeated BEAM copy churn, replaces per-request maps with references, and keeps a single always-in-memory dataset. Uses DynamicSupervisor, a registry and telemetry around long-lived servers inside a Phoenix app to host the personalization pipeline. Real case: a complex API pipeline whose memory usage scaled poorly is stabilized in production, reducing duplicated in-process memory and improving throughput.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 1:22Elixir and Phoenix benefits
- 2:25Backend patterns in Elixir
- 4:31Runtime memory boundaries
- 6:44Data sharing across processes
- 8:35Data copying in practice
- 11:49Exceptions to copying
- 13:13Shared references in nested data
- 14:17Cost of process copies at scale
- 15:22OTP process design
- 17:03GenServer for shared data
- 18:17Q&A
related talks
35mLeveling up your Phoenix Projects with OTP
23mElixir GenServer: Understanding Elixir concurrency model
37mKeynote: All Aboard The Stateful Train
45mTesting Asynchronous OTP
44mThe NeverEnding Application
46mBuilding a Realtime Websocket API in Phoenix
28mLobbying with Elixir: Real-Time LiveView and OTP
47mOTP