←BACK TO TRIP LOG [2]
DISPATCH LOG: WB 02
Chakravyuh - visual screen 1
FEATURED SPECIFICATION · 01/02
SYSTEM INTERFACE GALLERY [2 SCREENS]
Technical Lead & Core Engineering Team at Chakravyuh (IEI SCCSE)
Technical Lead & Core Engineering Team at Chakravyuh (IEI SCCSE)
01 — THE PROBLEM

What needed to be engineered

Campus treasure hunt competition required synchronized real-time state for 250+ concurrent users with zero cheating and resilient live leaderboards.

02 — HARD CONSTRAINTS

Boundaries & non-negotiables

  • [01]Tab and browser-switch detection: 5 chances, ban after more than 15 seconds away, admin unban.
  • [02]Low latency: sub-50ms leaderboard propagation under peak burst traffic.
  • [03]Decoupled architecture with composition root for dependency injection.
03 — ARCHITECTURAL BLUEPRINT

System flow & boundary isolation

CLIENT INGESTIONWebSocket / HTTPJWT · ECDH AuthEXECUTION CORENode.js OrchestratorCgroups · Worker QueueWall-time / CPU boundedISOLATION REALMEphemeral Pod / DBPostgreSQL · RDS

Modular Express.js backend with decoupled repositories, composition root DI, Redis pub/sub for instant score sync, and an automated rule engine.

04 — ENGINEERING DECISIONS & TRADE-OFFS

Why this choice over alternatives

Fair Grace-Period Ban Engine

Allowed 5 chances and an 15-second grace window to absorb accidental OS notifications without punishing honest players.

Centralized Composition Root

Injected dependencies at the application entry point, isolating test mocks from production PostgreSQL queries.

05 — RETROSPECTIVE & WHAT I GOT WRONG

TODO(Srayash): add post-mortem on websocket reconnection storm handling under erratic campus WiFi.

06 — PRODUCTION IMPACT

Verified delivery & outcomes

Successfully powered 250+ registrations; about 15 people were auto-banned and given second chances, 1 was permanently banned.