Concurrency planning
Planning for concurrent BigBlueButton meetings
Concurrency is the sum of what is happening at the same minute. A timetable, not an enrolment database, reveals the media peak your platform must survive.
Executive brief
What matters
- 01
Calculate 5- or 15-minute peaks; hourly averages hide join storms and timetable boundaries.
- 02
Track participants, rooms, webcam publishers, screen shares and recordings as separate dimensions.
- 03
In a Scalelite pool, standardise nodes and reserve enough spare capacity for maintenance or failure.
01
Turn the timetable into a concurrency curve
Export scheduled start and end times, then count overlapping sessions in short intervals. Add unscheduled rooms and sessions that run long. Overlay expected attendance rather than course enrolment. Term starts, examinations and all-hands events should be modelled as distinct scenarios.
02
Account for join storms
Classes often start on the hour, creating a burst of API requests, audio negotiation and webcam publication. Spread start times where the teaching model permits, instruct users to run preflight checks and monitor the first fifteen minutes separately from the steady state.
03
Balance meetings, not individual users
Scalelite exposes a standard BigBlueButton API, polls backend health and assigns a newly created meeting to a suitable node. The running meeting remains on that node. One unusually large session can therefore dominate a backend even when pool-wide participant count looks comfortable.
04
Operate with headroom
Choose an alert threshold and a separate admission threshold. Capacity should cover the planned peak while a node is being drained or repaired if availability matters. Review placement, meeting count and recording processing across nodes; a green load balancer does not prove acceptable classroom quality.
Evidence base
Sources and further reading
We prefer project documentation and first-party product guidance. Community links are included where they reveal recurring operational questions rather than establish product guarantees.
Practical answers
Questions teams ask
Can Scalelite move a live meeting to another server?+
No. It selects a backend when the meeting is created; a running meeting stays on that BigBlueButton node.
Are ten 20-person rooms the same as one 200-person room?+
Not necessarily. Meeting overhead and media patterns differ, and the single large room may exceed recommended session size even if totals match.
How much spare capacity is enough?+
Derive it from your failure target and load tests. A pool expected to tolerate one node outage needs more than ordinary demand divided evenly across all nodes.
Continue the research
Related guides and infrastructure
How to size a BigBlueButton server
Size BigBlueButton servers using concurrent meetings, participants, webcams, screen sharing, recordings and measured headroom.
Read next → Planning & architectureScalelite architecture and operations
Understand Scalelite load balancing, PostgreSQL, Redis, shared recordings, node lifecycle, monitoring and failure modes.
Read next → Technical guideHow many users per BigBlueButton server?
Estimate concurrent BigBlueButton users responsibly by accounting for meetings, webcams, screen sharing, recording, CPU and bandwidth.
Read next →