In the fast-paced environment of large-scale events, the difference between a smooth entry and a chaotic bottleneck often comes down to seconds. During the AIORI-2 Hackathon, Team Wi-Fighters from the Vemana Institute of Technology addressed this by building QR-DB: a high-speed, secure, and real-time event check-in system that moves beyond simple links to sophisticated session-token validation.
1. Beyond the Static Scan: The “Real-Time” Pulse
Traditional QR check-ins often involve a “scan and pray” approach where the user fills a form and the organizer manually refreshes a list. QR-DB changes the game by using Server-Sent Events (SSE).
When an attendee scans the code, the dashboard updates instantly (~150ms) without a refresh. This creates a “live pulse” of the event, allowing organizers to see attendance spikes and duplicate attempts in real-time.
2. Security Architecture: JWTs and Short-Lived Tokens
Speed is nothing without security. Our system implements a multi-layered authentication stack based on IETF standards:
- ISO/IEC 18004: Ensures the QR structure is universally readable.
- JWT (RFC 7519): We embed short-lived, verifiable tokens in each QR session. Even if a user takes a screenshot, the “token” can be set to expire, preventing unauthorized entry after the event window.
- OAuth 2.0 (RFC 6749): We integrated Google OAuth to ensure only approved organizers can access the sensitive attendance data.
3. The Technical Stack
To ensure 99.9% reliability during “burst” check-in scenarios, we utilized a robust cloud-native stack:
| Component | Technology | Role |
|---|---|---|
| Backend | Django REST Framework | Handles token logic and API routing. |
| Real-Time | Server-Sent Events (SSE) | Unidirectional server-push for live updates. |
| Database | PostgreSQL (NeonDB) | Stores atomic, unique scan logs. |
| Security | PyJWT / Google OAuth | Token generation and identity verification. |
4. Solving the “Race Condition” Duplicate
A major challenge in digital check-ins is the “double-tap”—when two scans happen so fast the database tries to record both. We implemented DB-level idempotency. By setting a unique constraint on the User+Session token, our PostgreSQL backend automatically rejects duplicates at the hardware level, ensuring 100% accurate attendance counts.
5. Lessons from the AIORI Testbed
Our sprints revealed that network resilience is the “hidden” requirement.
- The Reconnect Heartbeat: We found that SSE streams can drop on weak Wi-Fi. We added a custom sse-manager.js that performs an automatic heartbeat check and silent reconnect.
- Server as Truth: We learned never to trust the scanner’s device time for expiration; the Django server remains the absolute authority for session TTL (Time-to-Live).
“Implementing the QR-based check-in flow gave me hands-on experience with OAuth, token handling, and dashboard-level permissions.” — Shaik Raheema, Team Member
6. Future Roadmap: The “Regenerating” QR
Our next phase involves QR Rotation Mode. Much like a TOTP (Google Authenticator) code, the QR code on the organizer’s screen will regenerate every 30 seconds. This makes it impossible for participants to “proxy” check-in for friends by sending them a photo of the code.
Read the full report
