The constraint
Keep rankings fresh and consistent while thousands of players generate events concurrently.
Case study · iGaming · Real-time
Real-time Tournament System
An enterprise tournament platform that accepts gameplay events from multiple operators, maintains live rankings, applies configurable reward rules, and publishes targeted leaderboard updates.
request lifecycle
architecture.flowBet API
Event Bus
Scoring Worker
Redis
WebSocket
The solution
Separated command ingestion from scoring and read models. Durable events drive idempotent scoring workers, while Redis-backed leaderboard projections serve the latency-sensitive read path and WebSockets deliver targeted updates.
architecture highlights
- Event-driven microservices
- CQRS read models
- Idempotent scoring
- Distributed cache
- Realtime pub/sub
scalability considerations
- Partition consumers by tournament
- Keep scoring workers stateless
- Apply backpressure at the event boundary
- Rebuild projections from durable events
project outcomes
- 10K+ concurrent users
- 50ms average API response
- 99.9% uptime
- Zero data loss during peak loads
runtime.dependencies
Technology stack
NestJSMongoDBRedisAzure Service BusWebSockets
engineering ownership
My contribution
Designed the event boundaries, read-optimized leaderboard path, and horizontally scalable consumers.