Start from concurrent users, not accounts
Registered users and monthly active users do not determine real-time load. Count the maximum people expected online at once, how they are divided into meetings and what media they will publish.
The official rule of thumb
BigBlueButton documentation has historically used roughly 200 simultaneous users on a server meeting the minimum requirements as a planning rule of thumb, while warning that workloads vary and recommending no single session above 200 users. Treat this as a test hypothesis, not an SLA.
Webcams change the shape of load
More published cameras, screen sharing and recording increase processing and bandwidth. Define at least a light, typical and peak scenario before choosing node count.
Scale out before the ceiling
A Scalelite pool lets new meetings land on less-loaded nodes. Keep operational headroom for spikes, updates and node failure instead of designing around a theoretical maximum.
The operational reality
BigBlueButton capacity depends on how people use media. Hardware specifications help narrow the choice, but your own load test, monitoring and failure plan turn that choice into a production design.