A measurement stand proved the team's recording hypothesis wrong
Call recording runs in its own pod: a headless Chrome opens the meeting page and captures the picture from it. On heavy calls that pod either hit the CPU ceiling or died on memory, and users saw one thing - the recording stopped.
The popular hypothesis sounded reasonable: switch the recording page to speaker view, show one active speaker instead of a nine-camera grid, and the load will drop. Before writing any of that I built a measurement stand: several meeting scenarios, equal duration, CPU and memory captured per run.
What the numbers said
A normal meeting fit within limits comfortably: CPU peaked around 2.8 cores against a limit of 4, memory 1-2 GB, zero restarts. A heavy scene pushed the pod to 7.7 cores and 5.4 GB, and at the memory limit it got OOM-killed.
Speaker view saved nothing. Recording cost comes from two parts: the constant encode of the output stream plus receiving every incoming track. The first part does not care what is drawn on screen, the second depends on how many people are in the call, not on the layout. Removing the grid removed only the rendering, the cheapest line in the bill.
The real lever was elsewhere: stop subscribing to tracks that never make it into the recording. I did that, and the recording broke - selective subscription dropped exactly the pieces that were needed. Reverted it. The release got only the safe half of the optimisation, while the risky one stayed in a branch with a note explaining why it does not work.
The side finding that mattered more
While digging I ran into something nobody was looking for. The recording page reused the production participant grid, and that grid caps at 16 tiles per page with no pagination in recording mode. On a 50-person meeting the file captured the first sixteen, and the rest were silently absent.
That is not performance, that is correctness: people received a recording that looks complete and isn’t. It surfaced only because I went into the recording page with measurements rather than with an answer already in hand.
What it taught me
A neat hypothesis is worth exactly as much as the measurements under it. Had I gone straight to writing speaker view, the work would have taken days and delivered nothing - and there would have been no way to explain why “the optimisation didn’t help”.