We spent last Thursday in the conference room with the network diagrams spread across the table. The agenda was narrow: how to route internal town hall streams from the Kuala Lumpur HQ to three regional offices without overloading the existing MPLS links. The usual answer is to push everything through the central data center, but that adds latency for the Singapore and Jakarta sites. We ended up sketching a different topology, one that puts an edge relay in each office and keeps the high-bitrate feeds local. The tradeoff is more hardware to maintain, but the latency drop is worth it. This post walks through the decisions we made, the numbers we checked, and the questions we still have open before we commit to the build.
The first thing we did was map the actual usage patterns. Most internal broadcasts are not continuous; they are scheduled events, usually a monthly town hall, a quarterly training session, or an emergency announcement. That changes the sizing problem. We do not need a permanent high-bandwidth path to every office. We need a burst-capable path that can handle 30 to 60 minutes of heavy traffic a few times a month. That distinction shaped everything else in the session.
We also looked at the encoding side. The current setup uses a single HLS stream at 1080p, which is fine for desktop viewers but wasteful for the mobile clients that make up about a third of the audience. We agreed to test a multi-bitrate ladder, starting with 720p as the baseline and adding a 480p variant for the field teams on cellular connections. The relay nodes will handle the transcoding, so the origin server stays simple.
The open question is failover. If the Jakarta relay goes down mid-broadcast, we need a fallback path that does not require manual intervention. We are leaning toward a simple health-check mechanism that reroutes to the Singapore relay, but we have not validated the recovery time yet. That is the next step before we finalize the deployment plan.
Read the follow-up on the first week of testing · Browse all posts