Silent message loss in Phoenix.PubSub when scaling to a second non‑clustered node

Goal: Determine the safest, lowest‑cost approach to handle Phoenix.PubSub when a low‑traffic application might later be scaled to a second node.

Constraints: The current cheapest setup runs a single release with server mode enabled, relies on the default PG2‑style PubSub adapter, and accepts a brief availability gap during each deploy. Adding a second node without clustering causes silent message loss, breaking Channels and Presence without any error log.

Uncertainty: Whether to introduce clustering (e.g., libcluster) or a centralized adapter such as Redis now, or to defer the change until traffic growth justifies the extra operational complexity and cost.

What are the operational trade‑offs of adding libcluster now versus waiting for higher load? How does switching to a Redis‑based Phoenix.PubSub adapter affect restart time and memory footprint on a small node? Which monitoring strategy can reveal silent PubSub gaps before a second node is introduced?