Guest Onboarding Scales Past the Help Desk
A venue offers guest Wi-Fi through a captive portal with self-registration. Attendance grew from 300 to 3,000 daily guests. The help desk is overwhelmed with portal failures, and security wants to limit guest session length and bandwidth while keeping the experience simple. The current portal uses a single shared PSK behind the scenes and no per-user accounting. Sponsors occasionally need to grant extended access.
1. Redesign guest onboarding to scale to 3,000 daily users while meeting security and simplicity goals.
Read the worked answer
Move from shared-PSK self-registration to a per-user captive portal with accounting:
- Self-registration with unique credentials (email/SMS or voucher) so each guest is individually identified - no shared PSK.
- Role-based policies for session timeout and bandwidth limits applied per guest role.
- Sponsor workflow for extended access, with sponsor accounts able to approve/upgrade specific guests.
- Accounting/RADIUS to track sessions and enforce limits.
- Keep the portal simple: minimal fields, clear messaging, and a fallback path if registration fails.
This scales because onboarding is self-service and policy is enforced by role, not by manual help-desk action.
2. How would you validate that session limits and bandwidth controls actually work under load?
Read the worked answer
Test with representative load:
- Register multiple guests and confirm each gets a unique identity and correct role.
- Verify session timeout terminates the session at the configured limit.
- Measure throughput against the configured bandwidth cap per guest.
- Confirm sponsor-granted extended access overrides the default limit for that guest only.
- Check accounting records reflect sessions and usage.
- Run at peak-like volume to confirm the portal and RADIUS handle 3,000 users without failures.
Document results and adjust limits if guest experience degrades.