Design a Screen Recording & Sharing Service

Problem statement

Design a screen recording and sharing service where a user captures their screen, optionally with a camera bubble and microphone narration, and gets a shareable link within seconds of stopping the recording. The platform must run a capture client on desktop and browser, upload large media files reliably over hostile networks, transcode and package renditions, generate short share links with graded privacy, serve adaptive-bitrate playback through a CDN, and integrate with workplace tools such as Slack and Trello.

This is not a clone of a general video site. Three properties change the architecture. First, latency-to-shareable is the product: a recording that takes ten minutes to process feels broken even if it eventually works, so the pipeline must make the video watchable before full-quality processing finishes. Second, the client is a first-class distributed system component: capture produces a continuous high-bitrate stream that must be buffered, encoded, chunked, and resumed across network failures without user intervention. Third, most recordings are short-lived and business-scoped: a demo sent to a teammate has a different privacy, retention, and access pattern than a public tutorial, so link semantics and revocation matter more than recommendation ranking.

Why the problem is distinctive

A general video platform optimizes ingest of finished files, long-tail storage, and discovery. A screen-sharing product optimizes a tight loop: stop recording, get link, paste into chat, viewer clicks and plays within two seconds. Every architectural decision is judged against that loop. The master file may still be uploading when viewers arrive. The first playable rendition must be produced from partial data. The share link must exist before encoding completes. This forces a proxy-first encoding strategy, resumable streaming uploads, and a resolution layer that can answer before the media pipeline does.

Public operating baseline

Public evidence shows the category is real and scaled. Loom reports more than 25 million users and more than 200 million recordings created, and was acquired by Atlassian in 2023 for a reported $975 million; Loom engineering materials describe using Mux for video processing and AWS object storage with CDN delivery. Vimeo publicly reports on the order of tens of millions of hosted videos and supports the open tus resumable upload protocol. Mux states its data product has tracked billions of video views and sells the upload, transcode, and deliver primitives as APIs. Zoom reported 300 million daily meeting participants at its 2020 peak, demonstrating mass concurrent capture behavior even though meetings are a different product. These are cited company figures for context, not targets for this design.

Design assumptions

For capacity planning this answer assumes a mature product: 5 million registered users, 1.5 million daily active users, 500,000 recording attempts per day, 10 million playback starts per day, and a 5x event peak driven by work hours, launches, and training seasons. Unless tied to a citation, every number is a stated assumption, budget, or target.

The four architectural planes

1. Capture plane: screen, camera, and audio acquisition; local encode; fragmenting; buffering; resume.
2. Ingest and processing plane: resumable upload, master storage, probe, proxy encode, rendition ladder, packaging, thumbnails.
3. Delivery plane: share links, playback authorization, manifests, CDN, caching, embeds.
4. Collaboration plane: workspaces, comments, reactions, analytics, integrations, admin, retention.

A strong answer keeps these planes decoupled. Uploads keep flowing when encoders are saturated. Links keep resolving when the analytics pipeline lags. Playback keeps starting when collaboration features fail.