Screen sharing feels simple from the outside — you click a button, and everyone in the meeting sees your desktop. But underneath, it is one of the harder real-time media problems to solve well, especially the moment you scale a call from five people to a hundred. In this guide we design that system from scratch: a video-conferencing platform’s screen-sharing feature that must serve up to 100 concurrent viewers of a single shared screen, without the picture turning to mush or the presenter’s laptop fan spinning up like a jet engine.

Screen sharing began in the early 2000s with remote-desktop and web-conferencing tools like WebEx and GoToMeeting. Those early systems worked by taking periodic screenshots of the presenter’s screen, compressing them as images, and pushing the images to viewers every second or two. This was acceptable for static slides but terrible for anything with motion — a mouse cursor dragging a window looked like a slideshow, not a video.

The next generation, arriving with better codecs and broadband internet, treated the screen as a low-frame-rate video stream (5–15 frames per second) rather than a sequence of images. This is roughly where most modern platforms — Zoom, Google Meet, Microsoft Teams, Webex — still sit today, because screen content behaves very differently from camera video: it has long static periods (someone reading a document) punctuated by bursts of sharp motion (scrolling, video playback, or dragging a window), and it contains fine text and thin lines that regular video codecs tend to blur.

The arrival of WebRTC around 2011–2012 was the turning point for this entire industry. WebRTC gave browsers and native apps a standardized, royalty-free way to capture, encode, and transmit real-time audio and video (including screen content) directly between peers, using protocols like SRTP for encrypted transport and ICE/STUN/TURN for traversing NAT and firewalls. Screen sharing at scale, though, is not something you can do with the “peer talks directly to peer” model that WebRTC started with — sending your screen directly to 99 other people from your laptop’s upload bandwidth is a non-starter. That constraint is the entire reason media servers, and specifically the SFU (Selective Forwarding Unit) architecture, became the backbone of every serious video platform.

Today, screen sharing to 100 participants is a solved problem at companies like Zoom and Google, but it required rethinking almost every layer: capture, encoding, network transport, server-side routing, and client-side rendering all had to be redesigned around the specific statistical properties of screen content rather than camera video. That is exactly the system we will build in this guide.

The architecture has to solve one central tension: the presenter has limited upload bandwidth (often 5–20 Mbps on a home connection), but up to 99 viewers need that same video stream, each potentially at a different quality level depending on their own network and device. Sending 99 individual streams directly from the presenter’s machine (a full mesh) would require 99× the upload bandwidth — completely impossible. So the system is built around a central relay layer.

High-Level Component Map

Why an SFU and Not a Mesh or an MCU

There are three classic topologies for multi-party real-time media, and the choice between them is one of the most common interview questions in this space.

Why Screen Sharing Is Architecturally Different from Camera Video

It is tempting to treat “share my screen” as just another video track and reuse the camera pipeline, but screen content has different statistics that change several design decisions:

• High spatial detail, low temporal motion: Text and UI elements need sharp edges preserved; regular video codecs tuned for natural motion tend to blur text. Screen sharing typically uses a “content type: screen” hint that tells the encoder to prioritize spatial detail over frame rate.
• Bursty motion: Long static periods followed by fast scrolling or video playback inside the shared window. The encoder needs to react quickly — allocate more bits when motion appears, then drop back down.
• Resolution matters more than frame rate: Viewers generally forgive 5–15 fps for a shared screen, but they will not forgive blurry text. This is the opposite trade-off from camera video, where frame rate smoothness matters more.
• One-to-many fan-out is the common case: Camera video is usually many-to-many (everyone sees everyone), but screen share is typically one-to-many (one presenter, many viewers), which simplifies some parts of the design but makes the fan-out efficiency of the SFU even more critical.

Zoom in from the box diagram and each component reveals a set of deliberate choices — capture-then-skip, screen-content encoder modes, simulcast layers, an SFU decision loop per viewer, and keyframe economics tuned to bursty joins.

Capture

On the presenter’s device, the OS exposes screen or window capture APIs (for example, desktop duplication APIs on Windows, ScreenCaptureKit on macOS, or the Screen Capture API in browsers). The capture module grabs frames at a target rate, typically capped around 15–30 fps for screen content, since higher rates rarely help and only burn CPU and bandwidth. A key implementation detail: the capture module should detect “no change” frames (a static screen) and skip encoding them entirely, relying on the encoder’s inter-frame prediction rather than pushing redundant full frames.

Encoding for Screen Content

The encoder — typically H.264, VP9, or AV1 depending on platform and device support — is configured with a “screen content coding” mode when available. VP9 and AV1 in particular include explicit screen-content-coding tools (like palette mode and intra block copy) that dramatically improve compression of flat-color regions and repeated patterns common in UI content. The encoder targets a variable bitrate with a cap, and uses scene-change detection to insert a fresh keyframe when the presenter switches windows or opens a new application, since the picture has changed completely and delta-frame prediction from the old screen would be wasteful.

Simulcast and SVC: Serving 100 Viewers at Different Qualities

This is the single most important scaling mechanism in the whole system. Not all 100 viewers have the same network quality or screen size — a viewer on a phone over LTE cannot and should not receive the same bitrate as a viewer on fiber with a 4K monitor. There are two standard techniques:

The SFU’s Per-Viewer Decision Loop

For each connected viewer, the SFU continuously runs a small control loop: it monitors the viewer’s outgoing network conditions using RTCP feedback (packet loss, jitter, estimated available bandwidth via mechanisms like transport-wide congestion control), and dynamically switches which simulcast layer (or which SVC layers) it forwards to that viewer. If a viewer’s network degrades mid-call, the SFU downgrades them to a lower layer within one or two seconds; if it recovers, it upgrades them back. This is what allows the system to serve 100 viewers with wildly different conditions from the same underlying stream without the presenter’s encoder needing to know or care about any individual viewer.

Rendering on the Viewer Side

The viewer’s client decodes the incoming layer and renders it, typically into a canvas or native video surface. Because screen content is often viewed full-screen or enlarged, viewers apply a small jitter buffer (holding a few hundred milliseconds of frames) to smooth out network variability before decoding, trading a small amount of latency for a much smoother visual experience. Viewers also commonly implement “freeze frame” handling — if packets are lost and cannot be recovered via retransmission or forward error correction in time, the client holds the last good frame rather than showing corrupted video.

Keyframes and Their Outsized Role in Screen Sharing

A keyframe (or intra-frame) encodes a complete picture on its own, without referencing any previous frame, while subsequent delta frames encode only the differences from prior frames — a far smaller amount of data. Keyframes are dramatically larger than delta frames, sometimes ten times the size or more, which is why encoders try to minimize how often they are sent. But keyframes are also unavoidable in several situations that matter a great deal for screen sharing: whenever a new viewer joins mid-share and needs somewhere to start decoding from, whenever a viewer’s client detects it has fallen too far out of sync to recover cleanly through delta frames alone, and whenever the SFU switches which simulcast layer it is forwarding to a viewer, since that new layer’s delta frames reference a different frame history than the old one. A well-tuned system batches simultaneous keyframe needs where possible (for example, if ten viewers all join within the same second, requesting one keyframe from the presenter and distributing it to all ten rather than issuing ten separate keyframe requests), since an unmanaged flood of keyframe requests during a burst of new joiners can itself create a temporary bandwidth spike right at the presenter’s upload link.

Client-Side Adaptive Rendering Decisions

The viewer’s client is not a passive recipient of whatever the server sends; it actively participates in the quality decision by telling the SFU what it actually needs. If a viewer has minimized the meeting window or switched to another application tab, most platforms detect this and request a much lower layer, or pause the video entirely, since there is no perceptual benefit to spending bandwidth on a picture nobody is looking at. Similarly, if the shared screen is rendered as a small thumbnail alongside a gallery of camera video tiles, the client requests a layer whose resolution roughly matches what will actually be displayed, rather than always defaulting to the highest available quality — a small but meaningful optimization that, multiplied across 100 viewers in a call, meaningfully reduces total egress bandwidth without any visible quality loss.

Walking through a full lifecycle helps make the abstract architecture concrete. Here is what happens from the moment a presenter clicks “Share Screen” in a 100-person call.

Session Setup Phase

Before any media flows, the signaling server validates that the requesting user has permission to share (some meetings restrict sharing to the host), checks that no one else is already sharing (most platforms allow only one active screen share at a time per meeting, occasionally two side-by-side), and assigns the session to a specific SFU node, usually the one nearest the presenter geographically or the one already hosting the rest of that meeting’s participants.

Negotiation Phase

The presenter and the SFU exchange session descriptions (SDP) describing codecs, resolutions, and simulcast layers, and exchange ICE candidates to find the best network path — direct, or via a TURN relay if direct connectivity is blocked by NAT or firewall. This handshake typically completes within a few hundred milliseconds on healthy networks.

Steady-State Streaming Phase

This is the bulk of the session’s lifetime. The presenter continuously encodes and pushes frames; the SFU continuously forwards to each subscribed viewer at that viewer’s currently appropriate layer; each viewer continuously reports network feedback that drives the SFU’s adaptation decisions. New viewers can join mid-share (late joiners) by simply subscribing to the existing track and receiving a fresh keyframe so they can start decoding immediately, without disrupting anyone else.

Teardown Phase

When the presenter stops sharing (or disconnects), the signaling server broadcasts a “share ended” event, the SFU releases the forwarding state and buffers associated with that track, and viewers’ clients tear down their decoder pipeline for that stream. If the presenter’s connection drops unexpectedly rather than stopping cleanly, a timeout-based cleanup (typically a few seconds of no received packets) triggers the same teardown.

Every design choice here comes with a companion cost. The tables and text below name the ones you will be asked to defend in interview and encounter in production.

SFU Architecture Trade-offs

Simulcast vs SVC Trade-off

Simulcast is simpler to implement and has broad hardware encoder support (most devices can run 2–3 parallel hardware encoders), but it wastes upload bandwidth and CPU on the sender because multiple independent encodes of the same content are produced. SVC is bandwidth-efficient and elegant, but has historically been harder to deploy broadly because not all decoders and browsers support it equally well, and encoder complexity is higher. Many production systems use simulcast as the default and layer in SVC selectively for codecs and clients that support it well, such as newer AV1-capable devices.

The Fundamental Bandwidth vs Quality vs Scale Trade-off

At the core, this system is always trading off three things against each other: visual quality (resolution, sharpness of text, frame rate), server and network cost (bandwidth to serve 100 viewers), and scale (how many simultaneous large meetings the platform can support on its infrastructure). Pushing quality up for everyone increases bandwidth cost roughly linearly with viewer count; the system’s real job is to spend that bandwidth budget intelligently — giving good quality to viewers who can use it, and gracefully degrading for those who cannot, rather than uniformly capping everyone to the lowest common denominator.

We now scale this design to a platform-wide scenario: not just one 100-person call, but a video platform running many thousands of such calls concurrently, generating millions of signaling and media-control requests per minute across its infrastructure.

The Real Scaling Bottleneck: Bandwidth, Not Compute

For SFU-based systems, the dominant scaling constraint is almost always egress bandwidth, not CPU. A single 100-person screen share, if every viewer received a 1.5 Mbps stream, requires roughly 150 Mbps of sustained egress from one SFU node for that one call. A data center hosting a few hundred such large calls concurrently needs tens of gigabits per second of sustained egress — this is why video platforms invest heavily in points of presence close to users and negotiate direct peering with ISPs, rather than relying purely on generic cloud egress.

SFU Cluster Scaling Strategy

• Horizontal SFU scaling: Each SFU node handles a bounded number of concurrent streams/viewers (a practical ceiling based on CPU for packet processing/encryption and NIC bandwidth). New calls, or large calls exceeding one node’s capacity, are distributed across a fleet using a media router that tracks each node’s current load.
• Cascading SFUs for very large meetings: For a 100-person call, some platforms cascade SFUs — the presenter’s stream is forwarded once from the origin SFU to one or more “relay” SFUs in other regions or availability zones, each of which then fans out to its local cluster of viewers. This avoids the origin SFU needing 100 direct egress connections and reduces cross-region latency for geographically distributed audiences.
• Regional Points of Presence (PoPs): Placing SFU capacity physically close to users (edge locations) minimizes RTT and reduces the chance of congestion on long-haul internet paths, which matters enormously for screen sharing since even brief congestion causes visible stutter or blur.

Congestion Control at Scale

Every viewer connection runs a congestion control algorithm (commonly Google Congestion Control, GCC, or newer approaches like BBR-inspired bandwidth estimation adapted for real-time media) that continuously estimates the safe sending rate based on observed packet loss and delay trends. At scale, the SFU must run this per-viewer estimation efficiently — typically using lightweight, event-driven feedback processing rather than per-viewer threads, so a single SFU process can manage state for thousands of viewer connections without excessive context-switching overhead.

Capacity Planning Numbers (Illustrative)

Algorithmic and Data Structure Considerations

Internally, the SFU maintains, per viewer, a small state machine tracking current subscribed layer, last keyframe request time, and jitter buffer statistics — typically stored in fast in-memory structures (hash maps keyed by viewer/track ID) rather than any database, since this state is ephemeral and must be accessed with microsecond-level latency on every packet. Layer-switch decisions use simple threshold-based or exponentially-weighted moving average (EWMA) smoothing over bandwidth estimates to avoid oscillating rapidly between layers (a phenomenon called “quality flapping” that is more visually jarring than staying at a slightly lower quality consistently).

Bandwidth Estimation Under Sustained Load

At platform scale, bandwidth estimation cannot be treated as a per-connection problem in isolation, because thousands of independent congestion-control loops are all sharing the same underlying network links at various points — inside a data center, across peering links, and on the last mile to each viewer. A well-designed system monitors aggregate egress utilization per network path and per SFU node, and applies admission control at the session-assignment layer: if a node’s current utilization is already close to its safe ceiling, the media router simply refuses to place a new large call there, preferring a node with more headroom even if it is a few milliseconds further away. This kind of proactive admission control prevents the far worse outcome of accepting the call and then having every viewer’s individual congestion control loop fight for scraps of bandwidth simultaneously, which produces visibly worse quality for everyone rather than a clean, predictable placement decision upfront.

Handling the “Everyone Joins at Once” Spike

A very common real-world scaling pattern is the “top of the hour” spike, where a large fraction of scheduled meetings across the platform all begin within the same few minutes. This creates a burst of signaling requests (session creation, SDP negotiation, ICE gathering) that is very different in shape from the steady-state media-forwarding load discussed earlier — it is a control-plane scaling problem, not a bandwidth problem. The signaling tier needs to be able to absorb this burst through horizontal auto-scaling of stateless signaling servers, connection-pooling to the presence store, and, where possible, pre-warming SFU capacity in each region ahead of predictable peak windows (for example, the top of business hours in major time zones) rather than reactively scaling only after load is already observed.

Failure Domains

The system must tolerate failures at several levels: an individual SFU process crashing, an entire data center or availability zone becoming unreachable, network partition between regions, and transient packet loss on the public internet path to any individual participant. Each has a different mitigation strategy.

SFU Node Failure and Session Migration

If an SFU node hosting an active large call fails, the platform needs a fast recovery path. Common strategies include keeping session metadata (who’s in the call, current media state) in a separate, replicated presence store rather than only in the SFU process’s memory, so a new SFU node can be spun up and clients can reconnect and resume within a few seconds, requesting a fresh keyframe to resume rendering immediately rather than waiting for the next natural keyframe interval.

Graceful Degradation Instead of Hard Failure

Reliability in real-time media is less about “never drop a packet” (impossible on the public internet) and more about graceful degradation: momentarily dropping to a lower-quality layer under congestion is far better than a full stream disconnect. The system is architected so that every viewer’s connection independently degrades or recovers, meaning one participant’s poor network never affects the other 99 viewers.

Multi-Region Redundancy

Signaling servers and media routers are deployed across multiple regions behind global load balancing (often DNS-based or anycast), so a regional outage routes new session requests to a healthy region automatically. Active calls in an affected region may need to migrate viewers to a relay SFU in a healthy region, which is why maintaining session state outside of any single SFU’s local memory is important.

Retransmission and Forward Error Correction

For screen sharing specifically, because static/text-heavy content is extremely sensitive to visible artifacts, systems commonly use a mix of Negative Acknowledgment-based retransmission (NACK, asking the sender to resend a specific lost packet) for latency-tolerant moments and Forward Error Correction (FEC, sending extra redundant data so some loss can be reconstructed without a round trip) for latency-sensitive moments, switching between them based on current round-trip time and loss rate.

Client-Side Quality Metrics

Every client continuously reports Quality of Experience (QoE) metrics back to the platform: frames decoded per second, frame freeze events and their duration, resolution actually rendered, round-trip time, packet loss percentage, and jitter. These are aggregated to compute a synthetic “Mean Opinion Score” style quality index per session, which is the primary signal used both for real-time debugging and for longer-term product quality tracking.

Server-Side Metrics

• Per-SFU-node CPU, memory, and — most importantly — egress bandwidth utilization against its ceiling.
• Per-session active viewer count and current layer distribution (how many viewers on high/medium/low layer).
• Keyframe request rate (a spike often signals a scene-change storm or connection instability).
• Signaling server request latency and error rates for session setup/teardown.
• TURN relay utilization, since a spike often indicates NAT traversal issues in a particular network or region.

Real-Time Alerting

Given how latency-sensitive this system is, alerting thresholds are set tighter than typical web services — for example, alerting within seconds if a region’s average frame-freeze rate crosses a threshold, since by the time a human notices a dashboard anomaly, thousands of live meetings could already be degraded.

Distributed Tracing for Media Sessions

Each session and each viewer connection is tagged with a trace ID that flows through signaling, SFU assignment, and media forwarding logs, so that when a support ticket comes in (“my screen share was blurry for one viewer”), engineers can reconstruct exactly which SFU node handled that connection, what layer was assigned, and what the bandwidth estimation looked like at that moment.

Bare Metal / Dedicated Capacity vs Generic Cloud

Because egress bandwidth is the dominant cost and constraint for SFU workloads, many large video platforms run their media-forwarding layer on a mix of dedicated data center capacity with negotiated bandwidth pricing and direct ISP peering, rather than purely on generic public cloud compute, where egress bandwidth pricing at this scale becomes very expensive. Signaling, presence, and control-plane services, which are far less bandwidth-hungry, are more commonly run on standard cloud infrastructure for elasticity.

Global Points of Presence

SFU capacity is deployed across many geographic regions so that presenters and viewers connect to the nearest healthy node, minimizing latency and keeping traffic on well-peered network paths as much as possible before it has to cross the open internet.

Auto-Scaling Characteristics

Unlike typical stateless web services, SFU nodes are not trivially auto-scalable mid-session, because an active call’s media state lives on a specific node. Scaling instead happens at the “new session assignment” layer — the media router directs new calls to nodes with spare capacity — while existing nodes are drained (stopped from accepting new sessions, but left running existing ones) before being taken down for maintenance or scale-in.

Cost Optimization

Because bandwidth dominates cost, the most effective cost levers are: aggressive but perceptually safe bitrate capping per layer, cascading to avoid duplicate cross-region transit, and encouraging viewers to receive the lowest layer that still meets a quality bar (e.g., a viewer with a small window thumbnail of the shared screen genuinely does not need the 1080p layer, so the client should request a lower layer based on its actual rendered size, not just network capacity).

What Actually Needs Persistent Storage

Most of this system’s hot path is deliberately stateless or ephemeral — media packets are never written to a database. What does need durable storage: user accounts and permissions, meeting metadata (scheduled time, participant list, host), and, if recording is enabled, the recorded screen-share video files themselves along with their metadata.

Presence and Session State

Live session state (who’s currently in a call, who’s currently sharing, current SFU assignment) needs to be fast to read and write but does not need long-term durability — this is a classic fit for an in-memory data store (like Redis) with replication for fault tolerance, rather than a traditional relational database, since the access pattern is high-frequency small reads/writes with a natural expiry when a session ends.

Caching Layer

Meeting configuration and permission data (does this user have rights to share their screen in this meeting?) is read very frequently but changes rarely, making it a strong candidate for aggressive caching close to the signaling servers, with cache invalidation triggered on explicit permission changes rather than relying purely on TTL expiry, since permission changes need to take effect immediately for security reasons.

Load Balancing Layers

Recording Storage

If cloud recording of the screen share is enabled, the recorded stream is typically written to durable object storage, with a background transcoding pipeline generating a few standard playback resolutions after the fact, decoupled entirely from the live real-time path so recording load never impacts live call quality.

Service Decomposition

The platform is naturally decomposed into a handful of focused services: an Auth/Identity service, a Meeting/Session Management service (scheduling, participant lists, permissions), a Signaling service (real-time SDP/ICE exchange, usually over WebSocket), the SFU media-forwarding fleet (a distinct, specialized service class from everything else), a Presence service, a Recording/Transcoding service, and a Notifications service (meeting reminders, “someone started sharing” events).

Protocol Choices

Why Media Uses UDP, Not TCP

This is a foundational networking decision worth understanding deeply. TCP guarantees ordered, lossless delivery by retransmitting lost packets and blocking all subsequent data until the lost packet arrives — exactly the wrong behavior for real-time video, where a video frame from half a second ago that finally arrives is worse than useless; it’s better to simply drop it and move on to the current frame. UDP has no such guarantee, which is precisely why SRTP is built on top of it, with the application layer (not the transport layer) deciding what to do about loss — retransmit selectively via NACK, apply forward error correction, or simply accept the loss and let the decoder conceal it.

Inter-Service Communication

Within the backend, services that need to coordinate — like the Meeting Management service telling the Signaling service that a new participant was approved — typically communicate via a message bus or lightweight event system for loose coupling, while latency-sensitive control decisions (like the media router picking an SFU node) use direct low-latency RPC calls to avoid unnecessary queueing delay in the critical session-setup path.

Useful Patterns

Anti-patterns to Avoid

The design patterns above are not theoretical — they show up, tuned differently, in every major production platform. Comparing them is one of the fastest ways to see which trade-offs matter for which use cases.

Summary

The whole design is a story about spending expensive bandwidth wisely. An SFU is the fan-out primitive that keeps server compute cheap; simulcast or SVC is the adaptation primitive that lets 100 different viewers each get a quality suited to their own network without punishing the sender; cascading SFUs push the same idea across regions; and ephemeral session state, UDP-based transport, and screen-content-aware encoding are all supporting choices that only make sense once you understand which resource is scarce (network) and which is not (CPU).