Approach 2 · blue/green · PubSub over Redis

Same app. Different plumbing.

The same Phoenix LiveView application as the other host, deployed a different way: a StatefulSet per colour, no Erlang distribution between pods, and cross-pod messaging carried by Redis. Everything below is pushed over this page's WebSocket once a second.

live from the pod serving you demo-blue-0

Viewers, fleet-wide 0 Presence, replicated through Redis

PubSub transport redis not Erlang distribution

Erlang node nonode@nohost nonode@nohost — distribution never starts

Uptime, this pod 15m 2s resets when this colour is replaced

BEAM processes 424 one per connected LiveView, plus the runtime

Memory 80MB on musl, not glibc

Things to poke at

The same LiveViews as the other host. None ship client-side application JavaScript.

push Clock Server-pushed time, once a second state Thermostat Stateful control, events round-trip async Search Autocomplete with no client JS game Snake A game loop over a WebSocket game Pacman Sprite animation, server-driven push Rainbow High-frequency diff pushing state Image editor Live parameter manipulation telemetry Top Live BEAM process table db Users CRUD against Postgres, paginated

What to compare

Open both hosts at once

Each shows a fleet-wide viewer count and both are correct. One reaches that number over Erlang distribution; this one reaches it over Redis.

Watch the pod name

Here it is a StatefulSet ordinal that survives restarts. On the other host it is derived from the pod IP and changes whenever the pod is rescheduled.

Reload after a release

This host replaces a whole colour and moves new connections to it. The other host replaces pods one at a time and drains each.