Hey DEV community! 👋
Over the last few months, I’ve been locked in my room building Exam Flair—a full-stack Computer-Based Testing (CBT) platform designed to revolutionize how students prepare for exams.
Most exam prep tools are incredibly dry. They feel like reading a digitized textbook from 2005. I wanted to build something that actually keeps students engaged, so I decided to gamify the entire experience. It features real-time PvP challenges, live leaderboards, micro-learning modules, and an interactive 3D stunt bike game to keep things exciting between intense study sessions.
Oh, and I just turned 16.
Here is a breakdown of the architecture, the tech stack I chose, and the intense technical engineering challenges I had to solve to get this ready for launch.
🛠️ The Tech Stack
I wanted the platform to be fast, modern, and highly interactive. Here is what I used to build it from the ground up:
Frontend: HTML, CSS, and vanilla JavaScript. For the UI, I went heavily down the rabbit hole of luxury glassmorphism with deep blue and white themes to give it a premium, modern software feel.
3D Elements: Three.js. I built a 3D sci-fi stunt bike mini-game directly into the app. Getting the physics right so the bike shifts gears and moves gradually like a real motorcycle instead of snapping instantly between lanes was a massive math headache, but it works smoothly now!
Backend & Automation: Node.js and Python. I also ended up writing web automation scripts using Puppeteer to handle headless authentication, daily login trackers, and session persistence during testing.
🛑 The Hardest Engineering Challenges I Faced
Building the UI was the easy part. The real nightmare started when I began connecting the frontend gameplay to the backend server. Here are the three biggest bottlenecks I had to engineer my way out of:
Taming Three.js Animations & Render Loops
When you combine a 3D game loop with standard DOM elements, performance can tank fast. My initial animation loops were hogging the CPU, causing micro-stutters during high-speed bike movements. I had to strictly optimize my requestAnimationFrame hooks, implement delta-time calculations for frame-independent movement, and aggressively clean up geometries and textures in memory to maintain a locked 60 FPS.The WebSocket Multi-Connection Nightmare
Handling simultaneous PvP matches means managing a massive web of concurrent connections. Originally, when multiple users would join a PvP lobby at the exact same millisecond, state synchronization would lag, or worse, drop packets. I had to completely rewrite my connection-handling logic on the backend to ensure room states update atomically, and implement a graceful reconnection system for when a user's mobile data fluctuates mid-match.Scaling the Node.js Server
Node.js is single-threaded by default, which is great until hundreds of students start hitting the server to fetch quiz data, update leaderboards, and stream PvP states simultaneously. To prevent the event loop from blocking, I had to optimize my database queries, implement memory caching, and architect the backend so it can scale horizontally across multiple clusters without losing track of active PvP game sessions.
🚀 What's Next?
The core app, the PvP engine, and the 3D games are officially running smoothly. Right now, I’m building out the waitlist and getting ready to open up the first wave of beta testing.
As a solo, young developer, I would absolutely love to get the perspective of the senior engineers and production veterans in this community:
How do you handle horizontal scaling for stateful WebSocket connections (like active PvP rooms) when moving past a single server instance?
Are there any specific stress-testing tools you recommend for simulated multi-connection loads on a Node.js backend?
Drop your feedback, architectural advice, or questions below! I'd love to chat and learn from you all in the comments. 👇
