Design Screen Sharing - System Design | WinJob

Screen Share Problem and Context

Designing screen sharing means optimizing for smooth visual continuity under unstable networks while preserving confidentiality and predictable cost. A robust answer separates capture, encode, transport, fan-out, and render responsibilities so each stage can scale and degrade independently. This section focuses on operational decisions that keep frame delivery within p99 latency targets without causing reconnect storms.

Key mechanism

We use a relay-first architecture for enterprise networks, with sender-side simulcast layers and viewer-specific adaptation. Session metadata is stored separately from frame payload paths, allowing strict authorization checks without adding per-frame control-plane overhead. The receiver validates sequence continuity and requests targeted repair windows when jitter or packet loss creates gaps.

Reliability and degradation

Under stress, we degrade in a deterministic order: cursor trails first, annotation updates second, quality layer drops third, and only then frame rate reduction. This keeps meetings usable even when available bandwidth drops quickly. We maintain audit-safe logs for session joins, role changes, and recording toggles while keeping transient frame data out of long-term stores unless policy requires capture.

Interview edge

A strong explanation calls out ordering guarantees, replay limits, and explicit RTO/RPO boundaries for region failover. State what is eventually consistent (presence, soft indicators) and what must be strongly consistent (session ownership, policy enforcement, billing events).

javaOne Dark Pro

1 public record FrameEnvelope(String sessionId, long frameSeq, long timestampMs) {}

pythonOne Dark Pro

1 def should_drop_noncritical(feature: str, loss_rate: float) -> bool:
2     return loss_rate > 0.05 and feature in {"cursor", "annotation"}

typescriptOne Dark Pro

1 export function nextLayer(current: number, bandwidthKbps: number): number {
2   if (bandwidthKbps < 800) return Math.max(0, current - 1)
3   return current
4 }

Why interviewers care

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

The failure that defines the design

The outage to narrate is blurry, unreadable shared text. Screen content is mostly sharp static text and UI, but if you encode it like camera video — lossy, low-resolution, motion-tuned — the viewer sees mush exactly where it matters (code, slides, spreadsheets). The opposite failure is choking the network by sending every pixel at 30fps when the screen is static. The fix is content-aware encoding: detect static-vs-motion regions, send sharp keyframes of text at a low frame rate, and only ramp frame rate where there is actual motion. A screen-share system lives or dies on legible text, not smooth motion.

Key Highlights

•Defend every design choice using latency, availability, and cost evidence.
•Show deterministic degradation under congestion and reconnect bursts.
•Preserve strict correctness for policy and billing paths.
•Keep replay windows bounded and observable.

1	def should_drop_noncritical(feature: str, loss_rate: float) -> bool:
2	return loss_rate > 0.05 and feature in {"cursor", "annotation"}

1	export function nextLayer(current: number, bandwidthKbps: number): number {
2	if (bandwidthKbps < 800) return Math.max(0, current - 1)
3	return current
4	}