Waarom we voor realtime-projecten naar Phoenix en Elixir grijpen

De meeste teams behandelen realtime als feature flag. Je bouwt het product op een normale stack en plakt er een WebSocket-laag op zodra de klant om live updates vraagt. Die WebSocket-laag is half-gebroken, de rest van de codebase heeft geen mening over concurrency, en elke realtime-feature vraagt om een ervaren ontwikkelaar als babysitter.

Phoenix en Elixir keren dat om. Realtime is het fundament, niet een feature. De BEAM (Erlangs virtuele machine) is in de jaren tachtig gebouwd om telefooncentrales te draaien: miljoenen gelijktijdige verbindingen, gesuperviseerde process trees, hot code reload, fouttolerantie als eerste-klasse-zorg. Phoenix is wat je krijgt als een team compiler-nerds die runtime erft en er een web framework op schrijft.

Voor de realtime-workloads die we het vaakst releasen, operator-dashboards met honderden live databronnen, collaboratieve document-tools, multi-tenant SaaS met presence, is Phoenix het duurste om niet te gebruiken.

Wat Phoenix je geeft dat de reflex-stack niet biedt

De standaard Node-, Python- of Ruby-stack behandelt elk verzoek als een request-response cyclus. Concurrency is een library: je grijpt naar een queue (BullMQ, Sidekiq, Celery), een pub/sub-systeem (Redis, NATS), een WebSocket-server (Socket.io, ws), en een presence-tracker die je zelf schrijft. Elk onderdeel voegt operationele oppervlakte toe. Elk heeft zijn eigen faalmodus.

Phoenix vouwt die in het framework:

• Channels. Bidirectioneel, multi-topic, automatische reconnect. Op de draad dezelfde vorm als WebSockets, maar met backpressure, broadcast en per-channel auth als primitieven.
• PubSub. Een ingebouwd fan-out systeem dat horizontaal schaalt zonder Redis. 10.000 luisteraars op één bericht is een `Phoenix.PubSub.broadcast/3` aanroep.
• Presence. Het lastige 'wie is nu online' probleem opgelost met een CRDT eronder. Cursor sharing, room membership, join/leave events: in de doos.
• OTP-supervisie. Elk process is gesuperviseerd. Een crashende websocket-handler haalt de connection pool niet onderuit. Een buggy GenServer haalt de applicatie niet onderuit. De runtime herstart het kapotte stuk.

Wanneer het wint

Drie workloads waar Phoenix elk alternatief verslaat dat we hebben geprobeerd.

• Operator-dashboards met hoge data-fanout. Eén server die dezelfde delta naar 5.000 verbonden operationele bedrijven pusht. Phoenix gebruikt idle ongeveer 1GB RAM. De vergelijkbare Node + Redis-opstelling is drie machines en een coördinatielaag.
• Multi-user collaboratieve apps. Cursor sharing, presence-indicatoren, conflict-vrije updates. LiveView's stateful server-rendered model handelt dit af zonder SPA + state library combinatie.
• Per-tenant duurzame state. Een GenServer per tenant met game state, een inference queue, een billing meter, gesuperviseerd, herstartbaar, in-process. De Erlang Distribution laat dit werken over een cluster zonder code-aanpassingen.

Wanneer het verliest

Drie patronen waar we naar iets anders grijpen.

• Native-mobile-first producten. Phoenix helpt je niet bij het schrijven van de iOS-app. Je hebt nog steeds het SPA-vormige API-endpoint nodig dat de mobiele client consumeert.
• Anonieme publieke oppervlakken met extreme performance-budgets. Een high-traffic landing page, een CDN-cacheable read API. Elixir is snel, maar Rust aan de edge is sneller, en een statische site is gratis.
• Teams die geen Elixir-maintainer behouden. Senior Elixir engineers aannemen is moeilijker dan senior TypeScript engineers aannemen. Valt de codebase uit actieve zorg, dan is de Erlang-stack die je niet kunt lezen duurder dan de Node-stack die je wel kunt lezen.