Live Score API
Distributed backend system handling real-time sports data with horizontal scaling via Redis Pub/Sub, PostgreSQL transactions, and BullMQ background workers.
Visit Live Site↗
A horizontally-scalable WebSocket API handling real-time sports commentary across multiple server instances using Redis Pub/Sub and PostgreSQL transactions.
Overview
Live Score API is a distributed systems showcase built to solve the single-node limitation I encountered in earlier projects. Unlike traditional WebSocket demos that fail when scaled beyond one server, this system uses Redis Pub/Sub to synchronize broadcasts across multiple Node.js instances. Built with TypeScript strict mode and Docker Compose, it handles match state transitions, commentary broadcasts, and background job processing with guaranteed data integrity through ACID-compliant PostgreSQL transactions.
Experience Live Score API↗My Role
Architected and implemented the entire backend infrastructure, including the WebSocket server with Redis integration, PostgreSQL schema design with Drizzle ORM, and BullMQ background workers for scheduled match status transitions. Designed the horizontal scaling strategy and containerized deployment with health checks and monitoring.
Four services running simultaneously: API server (port 8000), background worker (BullMQ), Redis monitor (pub/sub operations), and PostgreSQL database—demonstrating distributed architecture in action.
Key Features
The system implements a distributed WebSocket architecture where each API instance tracks local subscribers but publishes to a shared Redis channel, enabling broadcasts to reach clients connected to any instance. PostgreSQL handles match state and commentary persistence with proper transaction isolation to prevent race conditions during concurrent updates. BullMQ manages delayed jobs for automatic match status transitions (scheduled → live → finished). The entire stack is containerized with Docker Compose for one-command local development and includes comprehensive health checks for Kubernetes-ready deployments.
Database schema design showing match entities, commentary history, and the relationship between WebSocket connections and Redis pub/sub channels.
Key Takeaways
Building Live Score API taught me why "it works on my machine" fails at scale. I learned to think in terms of distributed state—moving from in-memory Maps to Redis-backed pub/sub, implementing proper database transactions instead of fire-and-forget updates, and designing for horizontal scaling from day one. The project forced me to confront race conditions head-on, using PostgreSQL transactions to ensure inventory-like consistency in match state updates. This infrastructure-first mindset now informs how I architect all my projects, AI or otherwise.
TypeScript implementation of the dual-write pattern enabling horizontal scaling—broadcasting to local WebSocket subscribers for speed while publishing to Redis channels for cross-instance synchronization, replacing the single-node Map() limitation from earlier projects.
Live Score API demonstrates production-grade backend engineering without frontend complexity. By focusing purely on infrastructure concerns—horizontal scaling, data integrity, and background job processing—it serves as a reference implementation for distributed WebSocket systems. The project showcases the ability to architect stateful backend services that scale beyond a single node.
Mentora
↗Conversational AI tutoring with customizable voice‑interactive tutors in real time.
© 2026 NEMANJA