</> MAANG.io
system design · 301

Advanced

Master system design interviews with scalable architecture patterns, distributed systems, and real-world design challenges.

0/480 solved 0% complete

Section 6: One Meeting, One Owner - High-Level Architecture

Executive Summary: This section draws the whole system: edge gateways holding 30M sockets, a meeting owner service where each live meeting has exactly one owner, a placement directory that says where that owner lives, a hand-state store behind the owner, and an analytics stream on the side. We then trace two journeys through the same boxes. Maya's clap takes the lossy path and fits the 500 ms p95 budget. Maya's raised hand takes the durable path and is acknowledged within 300 ms. Along the way we defend the three choices the interviewer will press on: one owner per meeting, fan-out through gateways, and a store that only the owner can touch.

The interviewer slides the marker across: "Draw it." You have the numbers from Section 3, the messages from Section 4 and the data placement from Section 5. Each needs a home, and the firework and the flag must share a socket without the firework ever knocking down the flag.

The Whole System on One Whiteboard

High-level architecture: clients reach edge gateways over the signaling WebSocket; gateways look up the meeting owner in the placement directory and forward commands to it; the owner sends one frame per gateway, writes conditionally to the hand state store, renews its lease in the placement directory, gets reactionsEnabled and handRaiseEnabled from the meeting config service, and sends async per-minute rollups to the analytics stream and engagement store

Component Its one job Size at peak What it refuses to do
Edge gateways TLS, token validation, stamp participantId, local fan-out 30M sockets, 50K per node, 600 nodes, ~900 with headroom Make meeting-wide decisions
Meeting owner service One actor per meeting: coalesce reactions, single writer for hands ~3.9M meetings, ~10K per node, ~390 nodes Talk to clients directly
Placement directory meetingId to owner node, with lease and epoch One small record per live meeting Carry any meeting traffic
Hand state store Durable hand document, partition key meetingId 17K writes/s, ~4 GB hot Accept writes from anyone but the owner
Meeting config service reactionsEnabled, handRaiseEnabled (already exists) Read when the meeting is placed, then pushed to the owner on change Sit on the hot path
Analytics stream Reaction rollups and hand events for reports Async, droppable for reactions Block a live meeting

For transport, we reuse the signaling WebSocket every participant already holds for roster and mute; Section 4 covers why REST and the WebRTC media path lost.

Sign in to continue reading

The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.

Sign in to read the full lesson

Sign in to MAANG.io

Use your Google or Microsoft account — no password to remember.

Continue with Google Continue with Microsoft

Please accept the terms above to continue.