今日已更新 305 条资讯 | 累计 19865 条内容
关于我们

Building a Real Time Sports Scoring Engine with WebSockets and DynamoDB Streams

Kevin Coto🚀💡 2026年07月15日 08:49 0 次阅读 来源:Dev.to

The Problem Sports scoring sounds simple. One team scores a point, the number goes up, everyone sees it. But when you build it as a web application that needs to work on courtside tablets, spectator phones, and wall mounted displays simultaneously, with voice commands and tap controls, the architecture becomes more interesting. The project was Scoring AI, a voice enabled match scoring application for sports courts. Players start a match, share a link, and control the scoreboard from any device. The backend handles real time state synchronization, optimistic locking, idempotent score updates, rate limiting, and WebSocket broadcasting. The team was small. Me and a coworker who handled the CI/CD side. We were at the same level, both full stack, and we designed the system together. He focused on the deployment pipeline and infrastructure automation. I focused on the application layer, the real time system, and the frontend. But the architecture decisions were shared. This article covers the technical decisions we made and how patterns from previous projects influenced them. Why DynamoDB for Live Matches The match scoring data is different from the business data around it. A match lasts about an hour, gets updated frequently, and needs to be read by many viewers at once. After the match is complete, it is archived and rarely accessed. I had seen what happens when you put high frequency state updates into a relational database on a previous project. Row locks, contention, connection pool exhaustion. For Scoring AI, we used DynamoDB for the live match state and PostgreSQL for everything else. The hot path needed fast writes, optimistic locking, and automatic cleanup of abandoned matches. DynamoDB provides all of these. The version field on each match record acts as an optimistic lock. Every score update is a conditional write that checks the version has not changed. The cold path uses PostgreSQL through Kysely for user profiles, subscriptions, pricing plans, payment histor

本文内容来源于互联网,版权归原作者所有
查看原文