Hypothetical reference architecture: this article does not describe a deployed EU cluster, observed production topology, or measured result.
The HonarAmoozesh implementation used LiveKit and WebRTC for live participation, while NATS JetStream and Go supported application coordination. Its verified concurrency figure was more than 5,000 users at platform level. HLS playback became available hours later and was not a current-session audience path.
The design below explores a different system: a proposed multi-region service that could include a separate live broadcast path if product latency and interaction requirements allowed it. No result from that proposed path should be attributed to HonarAmoozesh.
Design goals
A multi-region SFU design would need to make room ownership, media placement, control-plane state, and failure recovery explicit. The goal would not be to move every participant continuously toward the geographically nearest node. It would be to keep room behavior predictable while containing failures.
A first implementation could evaluate Frankfurt as a central region and another EU region as a failure domain. The actual choice would depend on participant geography, data requirements, network measurements, provider constraints, and cost.
Routing decision table
| Session need | Proposed path | Decision boundary | Failure behavior to test |
|---|---|---|---|
| Live publishing or bidirectional participation | WebRTC through the room-owning SFU | Requires current-session interaction | Reconnect explicitly; never report the role active before media is ready |
| Live view-only broadcast audience | Optional live egress and HLS path | Use only when the product accepts broadcast latency and no immediate promotion guarantee is implied | Surface packaging or CDN failure; do not substitute delayed playback silently |
| Post-session playback | Delayed HLS | Separate experience available after processing | Keep unavailable or failed playback distinct from live-session health |
| Role change into live participation | New or updated WebRTC session | Authorization and capacity must succeed before the application marks the role active | Roll back or expose a recoverable pending state |
This table is a design artifact, not evidence that the optional live HLS row was deployed.
Regional room ownership
A proposed room-placement service would select one authoritative region when the room is created. Inputs could include the teacher or primary publisher location, expected interactive roles, available node capacity, and policy constraints. Room movement would be exceptional rather than continuous.
The ownership record would need one writer or a conflict-resolution rule. If two regions believed they owned the same room, the system would reject the ambiguity and use an explicit reassignment flow rather than trying to merge live media state.
Control-plane responsibilities
LiveKit would own media-session behavior. Application services would own authorization, roles, product state, and moderation workflows. Redis could hold short-lived placement or presence data, while NATS JetStream could carry durable application events where replay and explicit consumers were useful.
The exact technologies are replaceable. The important boundary is not: signaling state must not imply that dependent media state already exists. A role transition would remain pending until the client had joined the target WebRTC session and the required permissions were active.
Failure domains to exercise
A future implementation would need tests for at least these conditions:
- one SFU becomes unavailable during an active room
- control-plane events are delayed or replayed
- a region becomes ineligible after room placement
- a role change is approved but media readiness times out
- the optional live broadcast path fails while the WebRTC room remains healthy
- delayed post-session playback is unavailable without changing live-session status
No universal latency, capacity, availability, or cost threshold is proposed here. Each test would need a defined workload and an observable success condition.
Capacity-model inputs
A capacity model would separate publishers, interactive subscribers, view-only live consumers, rooms, subscribed layers, per-track bitrate, recording or egress work, and cross-region forwarding. A single total-user number would be insufficient because those workloads consume different resources.
The model could compare candidate room placements and audience paths, but its coefficients would need measurements from the chosen SFU build, codecs, hardware, and network. Until those inputs exist, the model remains a planning tool rather than a benchmark.
Primary references
- LiveKit distributed multi-region documentation
- LiveKit egress documentation
- NATS JetStream concepts
- WebRTC 1.0 specification
Engineering boundary
A multi-region media platform would be easier to operate when room ownership, current-session interaction, optional broadcast delivery, delayed playback, and role transitions are distinct concepts. This reference architecture remains hypothetical until it is implemented and tested against a stated workload and failure model.