Section 3: The Square of the Room - Scale Estimation & Workload Analysis

Executive Summary: This section turns human behavior into load. We derive 30 million concurrent participants at peak, 30 million sockets on about 900 gateways, 50K reactions per second at ingress, and a naive fan-out of 3.45 million deliveries per second, of which the 1% of people sitting in town halls cause about 43%. The lesson is that fan-out grows with the square of meeting size, that bandwidth is boring, and that burst message count is the real enemy. Raise hand, by contrast, comes out small: about 17K durable writes per second spread across 3.9 million meetings. One feature is a big, loss-tolerant workload; the other is a small, correctness-shaped one.

The interviewer caps the marker. "Before you draw boxes, how much load are we talking about?"

A number you derive in front of them is worth ten you recite, and the derivation is where the design's shape first appears.

From People to Concurrency

Start with behavior, and say each assumption out loud so it can be corrected.

Daily meeting participants:            100M
Meetings per participant per day:      3, averaging 45 min
Participant-minutes per day:           100M × 3 × 45   = 13.5B
Average concurrent participants:       13.5B ÷ 1,440   = 9.375M ≈ 9.4M
Peak-to-average (business hours,
  time-zone overlap):                  9.375M × 3      = 28.1M
Design peak:                                             30M concurrent

Concurrency hides what matters most here: how those 30M people are grouped. A reaction's cost depends on how many people share the sender's room.

Each row is participants ÷ average size (18M ÷ 5 = 3.6M meetings), and the mean meeting is 30M ÷ 3.9M ≈ 7.7 people. Most meetings are tiny. Our interactive cap is 1,000 participants; town halls (presenters plus mostly view-only attendees) go up to 10,000.

Quick check before moving on: