There is a basic information problem, where good people have it and bad people don't. You don't need cryptographicaly strong approaches, you just need speed bumps that impose costs on specific classes of attacker that disrupts their economy of scale. It's not a secrecy solution, it's an economic nudge.
Then there are ones with vs. without user interaction.
Without user interaction:
- rate limit join attempts so that you at minimum need proxies or a botnet to guess room names.
- do a simple entropy measurement of multiple attempts and rate limit anything that exhibits symmetry or monotonicity.
- add a "correct battery horse staple" style key to the url instead of or in addition to the 9 digit pin so the link is not easily guessable, but still has the mnemonic quality for people entering it manually.
- static personal room ID's only work with a passwd/token (not pin) whereas ephemeral ones can be chosen from a much larger search space. (yes, just add entropy)
- free sessions limited to 40mins or whatever should select from a name space large enough it will take a botnet to hit even one ephemeral session in the 40min timeframe.
- separate the invite link from the login link so that session owners can specify that the user needs to click from their email invite so it gets bound to the browser, and you zoom can set a token before redirecting them to the live session.
with user interaction:
- Obvious one would be a user PIN for ephemeral room IDs.
- Next obvious would be to choose a real security protocol and key management scheme (http://www.lsv.fr/Software/spore/index.html)
Rest of user interactive ones is exercise to the reader, as those are all solved problems.
The challenge is that they require keeping logical state at the application layer, which is specifically the kind of complexity you avoid in your scale-up architecture - and it burns you down the road.