The visible problem may look like one API or tuning value, but reliability is decided by state ownership, resource bounds, and recovery after failure. Allocations cannot migrate, so node loss breaks them. Recovery moves new credentials and connections quickly while the application protocol resumes tasks.
TURN is a metered shared relay, not merely an ICE URL. Operate short-lived authorization, allocation concurrency, byte accounting, regional capacity, and abuse response while preserving UDP, TCP, and TLS reachability.
Make the implementation decisions explicit
List non-negotiable invariants before selecting performance knobs. Tuning can roll out gradually; identity, permission, and terminal-state rules cannot drift at runtime.
- Keep config and firewalls as code, back up region-isolated secrets, withdraw the failed region, and verify remaining capacity before raising admission.
- Separate protocol facts, user intent, and automatic recovery; automation may restore facts but never overturn an explicit choice.
- Ship conservative defaults, server-side ceilings, and a rollout switch instead of trusting browser-provided numbers as resource budgets.
The delivery standard for TURN Disaster Recovery Beyond the Myth of Stateless Relays is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
Failure paths that are easy to miss
Failure and success must share one state model. An error toast that neither releases resources nor propagates a terminal state leaves dirty work for the next recovery attempt.
- A coturn config without its secret cannot authenticate, while shifting everyone to an unreserved region causes a second overload.
- A boolean failure cannot distinguish retryable, user-action, and permanent refusal, producing an endless loop.
- User or task IDs in metric labels create high-cardinality cost and leak unnecessary identity into diagnostics.
How to verify it before release
Do not stop verification when the final action succeeds. Count side effects, measure wait time, inspect privacy, and prove the next run begins from a clean baseline.
- Destroy a node, region, credential API, and secret replica separately; measure new-session RTO, task recovery, capacity, quota continuity, and secrecy.
- Run one hundred start, fail, retry, and cancel cycles; handles, listeners, queues, and temporary data must return to baseline.
- Cover direct, relayed, weak-network, background-tab, and mobile paths; do not rely on averages or one successful screenshot.
A capability becomes maintainable when it degrades safely, repetition adds no side effects, and its signals reveal a fault before user reports do.