Design Bandwidth Adaptation - System Design | WinJob

Context and Problem Framing

Bandwidth adaptation is the control system that keeps real-time communication usable when network quality changes every few seconds. In this section we lock decisions to measurable outcomes: startup delay, rebuffer ratio, bitrate stability, and visual/audio continuity. The design assumption is that clients emit telemetry continuously, the control plane converts telemetry into policy, and the media plane serves only renditions allowed by policy. This separation lets us scale each concern independently and keeps debugging straightforward during incidents.

For problem framing, we explicitly choose decision windows over instant reactions. Fast changes feel responsive, but if the algorithm reacts to every small spike, users experience quality flicker. A production-safe strategy introduces guardrails: minimum dwell time before upgrade, rapid downgrade on sustained loss, and buffer-aware pacing during recovery. We also keep network class detection simple: constrained, steady, and bursty classes with distinct behavior per class.

Capacity assumptions are concrete. At 1.2 million concurrent sessions and a 2-second telemetry cadence, the adaptation control plane processes roughly 600k telemetry events per second in peak windows. Control decisions are compact and cache-friendly, so persistence is append-only for analysis while hot state remains in memory with TTL. This keeps decision latency predictable and supports graceful failover.

Interview angle: state the objective function before architecture. A strong answer says we optimize for no-stall playback first, stability second, quality third. Then map each subsystem decision to those priorities. If an interviewer pushes cost constraints, show how chunk duration, ladder size, and telemetry frequency can be tuned without violating the top QoE targets.

Reference adaptation loop

javaOne Dark Pro

1 public class AdaptationController {
2   public int chooseBitrate(double throughputMbps, double bufferSeconds, int currentKbps) {
3     if (bufferSeconds < 4.0) return Math.max(300, currentKbps / 2);
4     if (throughputMbps * 1000 > currentKbps * 1.35) return Math.min(6000, currentKbps + 400);
5     return currentKbps;
6   }
7 }

pythonOne Dark Pro

1 class AdaptationController:
2     def choose_bitrate(self, throughput_mbps: float, buffer_seconds: float, current_kbps: int) -> int:
3         if buffer_seconds < 4.0:
4             return max(300, current_kbps // 2)
5         if throughput_mbps * 1000 > current_kbps * 1.35:
6             return min(6000, current_kbps + 400)
7         return current_kbps

typescriptOne Dark Pro

1 export function chooseBitrate(throughputMbps: number, bufferSeconds: number, currentKbps: number): number {
2   if (bufferSeconds < 4) return Math.max(300, Math.floor(currentKbps / 2));
3   if (throughputMbps * 1000 > currentKbps * 1.35) return Math.min(6000, currentKbps + 400);
4   return currentKbps;
5 }

Why interviewers care

Bandwidth Adaptation interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

The failure that defines the design

Two outages define bandwidth adaptation. The first is oscillation: the control loop overreacts, so bitrate and resolution sawtooth up and down, and the flapping is more jarring than a steady lower quality would be. The second is the slow receiver dragging everyone down: in a group call without per-receiver layer selection, the sender adapts to the worst link, so one person on hotel wifi degrades the whole call. The fix is the spine of the design: a closed control loop that estimates available bandwidth from congestion signals and adapts asymmetrically — drop down fast, probe up slowly, with hysteresis to stay stable — plus simulcast or SVC so the sender encodes layers once and the SFU forwards the right layer to each receiver. State asymmetric-adaptation-plus-per-receiver-layers up front, because adaptation is a control-stability problem and the disasters are thrash and one bad link poisoning the group.

Key Highlights

•Lead with QoE priorities: stall prevention, stability, then fidelity.
•Separate control and media planes to isolate scaling pressure.
•Use hysteresis and dwell-time rules to avoid oscillation.

1	public class AdaptationController {
2	public int chooseBitrate(double throughputMbps, double bufferSeconds, int currentKbps) {
3	if (bufferSeconds < 4.0) return Math.max(300, currentKbps / 2);
4	if (throughputMbps * 1000 > currentKbps * 1.35) return Math.min(6000, currentKbps + 400);
5	return currentKbps;
6	}
7	}

1	class AdaptationController:
2	def choose_bitrate(self, throughput_mbps: float, buffer_seconds: float, current_kbps: int) -> int:
3	if buffer_seconds < 4.0:
4	return max(300, current_kbps // 2)
5	if throughput_mbps * 1000 > current_kbps * 1.35:
6	return min(6000, current_kbps + 400)
7	return current_kbps

1	export function chooseBitrate(throughputMbps: number, bufferSeconds: number, currentKbps: number): number {
2	if (bufferSeconds < 4) return Math.max(300, Math.floor(currentKbps / 2));
3	if (throughputMbps * 1000 > currentKbps * 1.35) return Math.min(6000, currentKbps + 400);
4	return currentKbps;
5	}

Context and Problem Framing

Reference adaptation loop

Why interviewers care

The failure that defines the design

Key Highlights

Section Rescue Kit