How we built a real-time multiplayer coding arena that keeps every player's screen in step.
Applied R&D
Internal Engineering Benchmark
Most real-time features lag or fall out of sync once more than a handful of people share a session. We wanted to prove a low-latency approach that holds.
A real-time coding platform where people compete in live battles. We built it to prove that shared multiplayer state can stay in step across many players, without the lag and desync you usually hit.
Most 'real-time' features feel fine with three people and fall apart with thirty. We wanted a hard version of that problem in our own hands: live coding battles where half a second of drift decides who wins. So we built one and made the server the referee.
The interesting part isn't the UI. It's that scoring and state live on the server, guarded by distributed locks, so two events can't double-count and a late submission can't steal a win.
What was hard, and why it's worth solving well.
Users expect instant feedback, but keeping many people in sync in real time usually adds lag and data conflicts that kill the feel.
Live coding battles and progress tracking across players are easy to get wrong. Two clients disagree on who did what, and the score breaks.
A live code runner has to execute whatever a user types, without that becoming a way into our infrastructure.
The pieces that make it work.
Node-based paths that adapt as the learner progresses.
Takes away the 'where do I start?' for someone new.
A WebSocket arena for live 1v1 and group coding battles.
Turns solo practice into something competitive and social.
A sandboxed code runner that works straight in the browser.
You go from reading to running in seconds, not hours.
Redis and Postgres aggregate behaviour as it happens.
Instructors can see where people actually get stuck.
One view of velocity, engagement, and where a cohort is slowing down — not just who finished.
Instructors get a live read on how their group is actually doing.
Postgres materialized views plus Redis caching keep the heavier queries quick.
Node-based graphs that track progress and unlock the next challenge as you go.
A clear, gamified sense of where you are.
Recursive CTEs in Postgres handle the branching dependency trees.
1v1 and group coding battles with live leaderboard updates.
Practice becomes a game, which keeps people coming back.
A custom Socket.io setup tuned for frequent, small state updates.
Write and run code in several languages, with instant feedback, in the browser.
No local setup, so beginners aren't blocked before they start.
Isolated Docker containers run the code; the app talks to them over gRPC.
Next.js 14 with Server Components to keep the bundle small, and Framer Motion for the UI transitions.
A modular Node.js layer using Prisma for type-safe data access and an event bus for cross-service messaging.
PostgreSQL for durable data, and Redis for fast state, caching, and the Socket.io adapter that keeps battles in step across server instances.
A WebSocket layer built for frequent, small state updates rather than big payloads.
Every production system hides engineering decisions that don't show up in the UI. Here's what was actually difficult.
We broadcast only what changed — state deltas, not the whole state — so each update stays small and clients converge on the same picture.
“In real-time systems, what you don't send matters as much as what you do.”
All scoring runs on the server, and we guard battle start and scoring with Redlock distributed locks, so two events can't double-count and a late submission can't steal a win.
“In competitive real-time systems the server is the only source of truth. Never trust the client's timing.”
We keep a warm pool of isolated containers, so a run starts without waiting on a cold container, and user code stays sealed off from our infrastructure.
“For features like this, the infrastructure work matters as much as the code.”
EduScale is live, and that's the point. You can open it, start a battle, and watch two screens stay in step. It's a benchmark we keep coming back to: the same patterns here — server-authoritative state, distributed locks, a warm container pool — are what we'd reach for on a client's real-time feature.
3 weeks
From empty repo to live demo
Live
Deployed and open to inspect
Server-authoritative
Scoring guarded by Redlock locks
Tell us what you're building and where you're stuck. We'll tell you if we're the right team for it.