Niklas Weber

Problem: The 42 Heilbronn community ran table football and table tennis tournaments with no shared way to track who was actually good. Beyond just storing results, two students could report the same match slot within seconds of each other — naive rating recalculation is a textbook race condition, since an Elo update is a read-modify-write against a shared score and two concurrent submissions can't be allowed to read the same stale rating and both write back.

Solution: I built a complete Elo ranking system in Go with PostgreSQL, optimized from the ground up for performance. Match submissions run inside a transaction that locks both players' rows before applying the rating update, so concurrent reports serialize instead of clobbering each other, while reads — the public leaderboard, player profiles, match history — stay on a separate fast path. The backend served a React frontend with live leaderboards, detailed player profiles, and historical match data.

Technical Approach: Composite indexes on the columns the leaderboard and history views actually filter and sort by, plus Redis for the aggregate stats (win/loss streaks, rating deltas) that don't need to be recomputed on every request and get invalidated on write instead. Go's goroutines handled concurrent API traffic cleanly since each match update was isolated to its own transaction. I profiled throughout development to find and remove the slow paths rather than guessing at them. Similar optimization patterns appear in other systems projects like the raytracer, where every algorithmic decision has direct performance implications.

Results & Learnings: The system achieved 30ms average response times and maintained 99.9% uptime across tournament seasons, and the row-locking approach never produced a double-counted match under concurrent load in practice. Query optimization and profiling-driven development are non-negotiable for systems that prioritize performance. The project is now archived and no longer under active development.