avg websocket rtt ms
Fact50
Case Study
Updated: 2026-04-02Crazy - Multiplayer Card Game
A real-time, full-stack multiplayer card game where players create/join rooms, receive dealt hands, play cards according to configurable rules, and the server enforces rule effects and turn progression. Provides low-latency synchronized ga...
Scope: full stackdeveloperDuration: 3 monthsYear: 2025Architecture: platform
Repository Links:
Key Engineering Facts & Architecture Specs
Structural Invariantsavg room state kb
Fact5
estimated rooms per instance
Fact200
Architecture View
Processing state: architecture signal graph is initializing...
Architectural Decision Log
Trade-Off AnalysisUse Redis as canonical game state store with TTL
Low-latency reads/writes, easy serialization of full room state, native TTL for cleanup.
Trade-off: No long-term history; Redis outage stalls game; requires careful serialization and atomic updates to avoid race conditions.
Event-driven single-process Socket.IO server
Simpler development, direct in-process calls from handlers to service layer, lower operational complexity at small scale.
Trade-off: Scaling requires sticky sessions or a Socket.IO adapter (Redis adapter) and additional coordination; single-process increases blast radius for faults.
Separate Rule Engine (RuleService) from transport
Improves testability and keeps real-time handlers focused on event flow.
Trade-off: Additional indirection; needs thorough unit tests to ensure correctness.
Architecture Narrative
Challenge
Provides low-latency synchronized gameplay and session persistence for short-lived multiplayer card sessions with reconnection support.
Solution
Event-driven monolith (single Node.js process hosting an Express HTTP server + Socket.IO real-time layer) with an in-memory persistence tier (Redis) used as the canonical game state store.
Result
Key measurable signals: avg_websocket_rtt_ms (50), avg_room_state_kb (5), estimated_rooms_per_instance (200).
Trade-off Matrix
| Dimension | Selected Option | Impact | Compromise |
|---|---|---|---|
| Real-time transport | Socket.IO (WebSocket + polling fallback) | Reliable reconnects, ease of use, acknowledgements | Additional abstraction and potential overhead vs raw WebSocket |
| State persistence | Redis in-memory keys with TTL | Low-latency reads/writes, built-in expiry for stale sessions | No long-term audit/history and requires Redis availability |
Failure Modes & Resilience Analysis
Degradation ProtocolFailure Path & Recovery Invariants
Redis outage: Symptom: read/write failures when loading/saving room state; server startServer() will fail connect and exit.
What I'd Do Differently & Evolution
+
Add robust observability: Prometheus metrics, structured logs, and request/operation tracing (error rates, message rates, handler latency).
+
Harden concurrency around room updates: add Redis WATCH/MULTI or optimistic versioning to prevent lost writes and race conditions.