Design a live video-conferencing service

01Separate joining a room from hearing another person

A conferencing service carries interactive audio and video among two to twenty-five participants. Room creation, invitations and participant lists are control operations. Media packets carry the actual conversation. A connected signaling socket or a green room badge does not prove that anyone can hear or see another participant.

Ask how many participants must interact, whether reduced video is acceptable under congestion, and whether the media server may access media. This design supports rooms of two to twenty-five, prioritizes audio and trusts the media server; recording and server-excluding encryption are separate extensions.

Use six people joining a weekly meeting. Each browser authenticates, obtains room permission, negotiates supported media settings and establishes a network path. It then sends encrypted audio/video and receives the tracks it is allowed to hear and see. A track is one audio or video stream, such as a microphone, camera or shared screen.

The complete flow is authorize room join → exchange connection information → establish transport → publish and subscribe to permitted tracks → adapt quality during the call. Begin with two browsers to make that flow concrete. Add a media forwarding server when the bandwidth cost of many direct peer connections becomes unacceptable. Recording, transcription and very large broadcasts are optional extensions, not prerequisites for a working interactive meeting.

02Functional requirements

Agree on what the service must do before choosing its components.

1. Create and join rooms. Create rooms and admit authenticated or invited participants. Invitations are scoped credentials, not access to every room.
2. Control live media. Publish and receive permitted microphone, camera and screen-sharing tracks, with microphone/camera controls and a current participant list.
3. Enforce room permissions. Let authorized hosts change roles or remove participants. Enforce decisions on actual publication and subscription, not only the visible participant list.
4. Reconnect a participant. Rejoin after a network change or media-server failure while preserving authorized room identity and checking current permission. Recording, transcription and very large broadcasts are outside the main scope.

03Non-functional requirements

Use these hypothetical requirements for the worked interview. Confirm the assumptions with the interviewer; the numerical targets require testing and are not measured results. For latency, p95 and p99 mean that 95% and 99% of measured delays, respectively, are no greater than the reported value.

1. Workload. Support two to twenty-five participants per room. Use 10,000 concurrent six-person rooms for the worked capacity estimate and test the more expensive 25-person case separately. Count actual media subscriptions and qualities, not just connections.
2. Join and conversational latency. Budget roughly 150–250 ms one-way media delay on supported network paths. Target p95 below three seconds from an authorized join request to first usable remote audio when another participant is publishing; exclude time the user spends granting device permission. These targets do not cover every geographic path or unusable client network.
3. Usable degradation and recovery. Prioritize audio while reducing video under congestion. Measure audio gaps, video freezes, join failures and reconnect time separately. Brief interruption is allowed during a network change or media-server failure; reconnection cannot recover packets already lost or restore an old encryption session automatically.
4. Permission freshness. Target removal within five seconds on healthy connected control paths, reconcile membership every fifteen seconds and stop affected sessions after sixty seconds without successful authority refresh. Reject stale invitations/reconnects after removal. This is an outage policy, not an instantaneous or globally strict revocation deadline.
5. Transport security. Encrypt media on each network leg and authorize track ownership and subscriptions. The initial design trusts the media server to process media; transport encryption is not end-to-end encryption that excludes that server. Keep invitation/session grants finite and network-relay access authenticated.

04Connect two browsers before adding a media cluster

One application server authenticates two participants and checks the room membership. A signaling connection carries messages between them: an offer describes supported codecs and proposed media, and an answer selects compatible settings. A codec is the method used to encode and decode audio or video. Signaling coordinates the call; it is not the channel that carries all media frames.

Finding a usable network path

STUN does not itself provide that relay service.

Once a usable path and encrypted transport are established, each browser sends its microphone and camera media to the other. The receiver buffers a small amount to smooth uneven arrival, decodes the packets and plays them. Report success from actual media progress, such as first received audio or video, rather than only signaling completion.

If one browser changes networks, it can renegotiate the connection and run connectivity checks again. The room session identifies the participant independently of that temporary transport. This baseline is complete for two people and supplies a reference for diagnosing later forwarding-server failures.

05Show why a peer mesh stops scaling

In a mesh, every participant sends a copy to each other participant. With six people each sending a 1.5 Mbps video, each uploads 5 × 1.5 = 7.5 Mbps. Across the room there are thirty directed video copies, or 45 Mbps before audio and protocol overhead. A weak home uplink can fail well before the application server becomes busy.

A selective forwarding unit, or SFU, receives each publisher’s stream and forwards selected streams to subscribers. With one 1.5 Mbps upload per person, room ingress is 9 Mbps. If everyone still receives everyone at that quality, server egress remains 45 Mbps. The SFU moves replication away from each browser; it does not eliminate output bandwidth.

At ten thousand such concurrent rooms, 45 Mbps per room means 450 Gbps of media-server egress, about 202.5 TB in one hour. This dominates ordinary room metadata. Twenty-five participants all receiving twenty-four 1.5 Mbps videos would consume 900 Mbps per room.

Quality selection changes this cost. One active speaker at 1.5 Mbps plus four small videos at 0.15 Mbps uses 2.1 Mbps per receiver, or 12.6 Mbps for six receivers. Count actual subscriptions and layers, not just room count, when planning capacity.

06Give rooms, sessions and tracks clear ownership

Create a room

POST /rooms

Create the room with an owner and policy.

Join operation

1. Authenticate the participant. Establish the caller’s identity.
2. Authorize this room. Check membership or the scoped invitation.
3. Return connection information. Supply a room session and signaling/media connection information.

The session identifies this join; it is not a permanent substitute for current room permission.

Signaling message fields

The service validates who may publish a camera, share a screen or subscribe to another track.

Room and track records

An invitation or client-provided role cannot override the server’s authoritative membership decision.

Use ordered room updates or a version number so a late “participant joined” message does not undo a newer removal in the UI or media controller. On reconnect, fetch current room state instead of rebuilding membership solely from an incomplete stream of old notifications.

Media packets have their own sequence and timing information. They do not each need a database transaction. The room database stores who may participate. The SFU uses that state to decide which live packets to forward, without querying the database for every audio packet.

07Make the SFU the final small-room topology

Assign each room to one appropriately located SFU. Participants negotiate their transport with it instead of maintaining a separate media connection to every other participant. The SFU receives tracks and forwards only the subscriptions selected for each receiver. It generally forwards encoded media rather than decoding and mixing every picture into one composite video.

The subscription controller prioritizes audio, the active speaker, pinned video and screen sharing according to the product layout. A mobile participant displaying four small tiles should not receive twenty-four full-resolution videos. The server checks room permission before allowing publication or forwarding a subscription.

One room on one SFU keeps the main design understandable and avoids inter-server media coordination. Place the room near its participants when possible, with capacity-aware allocation. A globally distributed room may still have unavoidable long paths; geography cannot be repaired by merely adding more application replicas.

Scale different rooms across many SFUs. Admission considers CPU, packets per second, network egress and active subscriptions, not only connected socket count. A server can exhaust its network budget while CPU remains moderate. Multi-region room cascades and very large calls are later topology extensions with additional bandwidth and failure behavior.

08Adapt media instead of accumulating old frames

Networks vary during a call. The receiver reports loss and timing information, and the sender/forwarder uses congestion feedback to reduce offered bitrate when the path cannot sustain it. Sending more packets into an overloaded link increases delay and can damage audio as well as video.

Simulcast lets a publisher send several independently encoded qualities of the same camera. For example, 1.5, 0.4 and 0.15 Mbps layers total 2.05 Mbps of publisher upload. The SFU can select a suitable layer for each receiver without producing every quality itself. This raises publisher work and ingress compared with one stream, but can greatly reduce unnecessary receiver traffic.

A jitter buffer holds a short window of arriving packets so uneven network delivery becomes smoother playback. A larger buffer tolerates more variation but adds conversational delay. Missing audio and video are handled with deadline-aware concealment, recovery or frame dropping; retransmitting an obsolete frame indefinitely is not useful live communication.

Prioritize audio under congestion and reduce video resolution, frame rate or subscriptions. Request a fresh keyframe when decoding cannot recover from missing reference frames. Screen sharing may need a different policy because readable text and a stable image can matter more than high motion frame rate. Measure perceived quality rather than maximizing raw bitrate.

09Enforce removal where media is actually forwarded

Removing participant P6

1. Authorize the host. The room service checks the host’s removal permission.
2. Save the decision. Persist the membership change and send it to the SFU.
3. Stop actual media access. The SFU stops P6’s publication and subscriptions and closes the associated session.

Updating only the participant list in the browser would leave media access unchanged.

Control notifications can be delayed or lost. Target removal within five seconds on healthy connected control paths. Independently reconcile membership every fifteen seconds, and stop affected sessions after sixty seconds without a successful authority refresh. Scoped session grants also have finite validity. These rules limit stale access during an outage, but do not prove immediate removal or a worst-case deadline across every failure.

Reconnect checks current membership and creates or refreshes a permitted session. A removed P6 cannot use cached signaling state to recreate subscriptions. Track ownership is tied to the authenticated session, preventing another client from publishing under a guessed participant identifier.

This design accepts a documented propagation interval between the durable removal decision and its enforcement by a healthy SFU. A strict worst-case revocation deadline needs a stronger timing and lease protocol and explicit failure assumptions. Keep that stronger guarantee in advanced discussion rather than quietly claiming it from an asynchronous notification.

10Reconnect a call without confusing transport and identity

When P2 switches from Wi-Fi to cellular, the previous network path may stop working. The client detects lost transport progress, contacts signaling and performs an ICE restart with current credentials and room state. Media can pause while the new path is negotiated. The participant need not appear as an unrelated new person, but old transport details are not assumed valid.

If an SFU fails, room allocation chooses a healthy replacement and clients reconnect their media to it. The new SFU loads current authorization and participants publish fresh transports and subscriptions. The service cannot copy a dead server’s in-flight packets into a seamless stream after the fact. Expose the interruption and optimize reconnection time.

If signaling briefly fails while media remains healthy, an existing call may continue under its current allowed session policy. New joins and permission updates are impaired, so the control failure still matters. If permission freshness expires, enforce the chosen fallback rather than keeping the session indefinitely.

TURN capacity is another recovery dependency. A call that always works on an office network can fail for users behind restrictive networks if relay allocation is exhausted. Monitor relay usage and test those paths deliberately; successful direct connections alone do not establish general reachability.

11Measure the conversation and test difficult networks

Track time to first audio/video, join success, round-trip time, packet loss, jitter, audio gaps, video freeze time, selected layers and reconnect duration. Monitor SFU ingress, egress, packets per second and CPU by region. Aggregate room health can hide one receiver whose connection is unusable, so retain privacy-aware per-session diagnostics with limited retention.

Test high loss, fluctuating bandwidth, restrictive network traversal, a slow receiver, Wi-Fi-to-cellular changes and a full SFU failure. Verify that audio survives reasonable video degradation and that subscription changes actually reduce output traffic. Load tests should reproduce realistic packet rates and layer switching, not only open thousands of idle sockets.

Test removal followed by a stale reconnect, invitation expiry, unauthorized screen sharing and permission authority outages. The expected behavior must match the stated grace and propagation policy. Restrict TURN use with authenticated short-lived credentials so the service does not become a public relay for unrelated traffic.

Recording is a separate authorized media subscriber if introduced later. It adds consent, storage, retention, gaps and encryption questions. End-to-end encryption excluding the server changes which processing is possible. Neither feature should be appended as a casual box without revisiting who may access the media and how participants are informed.

12Check the design against its requirements

Before closing, check the final design against the agreed requirements. FR means functional requirement and NFR means non-functional requirement; the numbers refer to the lists above. These are proposed validation checks, not test results.

13Rapid revision

Rehearse the numbered functional requirements and non-functional targets first. Use this table to recall the mechanisms, then close with the requirements check above.

Remember: Setup succeeds only when usable media arrives.

Close with: “I first connect two browsers completely, then use one SFU per small room to control upload cost and subscriptions. Congestion handling preserves conversation quality, and room authority governs actual forwarding. Failover reconnects media with a visible interruption; advanced encryption and global room topology are explicit extensions.”

Recall the key ideas

Answer from memory before opening each card. Explain why the choice works and what it costs. Revisit missed cards tomorrow.