Design a Secure Screen-Share System

Problem statement

Design a secure screen-share platform where a presenter generates a one-click session link, viewers join in real time, the presenter's desktop is captured, encoded, and streamed with end-to-end encryption, optional remote control is granted with explicit permission, and an ephemeral text or voice overlay supports collaboration. The brief restricts scope to screen share first: link generation, real-time desktop capture and streaming, permissioned remote control, and basic chat or voice overlay.

The defining property of this system is that the payload is someone's live desktop: credentials typed into forms, private documents, internal dashboards. A confidentiality leak is not a quality-of-service issue, it is a data breach. The design therefore inverts the priorities of a normal streaming system. A streaming platform optimizes uptime and bitrate; this platform optimizes confidentiality and session integrity first, then latency, then quality.

Why this is not just a video call

Screen content differs from camera video in ways that shape every layer. Screen content is mostly sharp text and flat colors with long static periods and sudden full-screen repaints. Encoders must protect text sharpness at low bitrate, and congestion control must react to bursty repaints rather than steady motion. Capture must stay below a small CPU budget or it degrades the very machine being shared.

Security-wise, the difference is sharper. Camera frames have modest sensitivity; a shared screen routinely shows passwords, tokens, and regulated data. That forces three structural decisions: media confidentiality must not depend on infrastructure trust (end-to-end encryption), session entry must resist link leakage and brute force (opaque tokens, waiting rooms, rate limits), and remote control must be a separately granted, revocable, audited capability rather than an implicit side effect of joining.

The three planes

1. Session plane: link creation, join, participant identity, waiting room, permissions, lifecycle.
2. Media plane: capture, encode, encrypted transport, SFU or peer forwarding, congestion response.
3. Trust plane: key agreement, key epochs, device attestation, audit, abuse controls.

A strong answer keeps these planes separate. The session plane may fail or degrade; the media plane must still encrypt; the trust plane must never be bypassed to improve latency. Whereby ships browser rooms that are end-to-end encrypted by default for small group calls, and Cisco rebuilt Webex encryption on Messaging Layer Security precisely because transport-level protection was no longer sufficient for their enterprise threat model. Those production choices confirm the core lesson of this design: for sensitive real-time content, end-to-end confidentiality is an architecture property, not a settings toggle.

Public scale context versus our assumptions

Public figures establish the category size. Zoom reported 300 million daily meeting participants in April 2020, and Google reported 100 million daily Meet participants the same year; Discord reported roughly 200 million monthly active users in 2023. Those are context, not our targets. For capacity planning this answer assumes a focused product with 6 million daily active users and 2.1 million screen-share sessions per day; every number without a company attribution is an explicit design assumption.