Building a Resilient Matchmaking System in Rust
During my second semester as an exchange student at Korea University, I took the class ICT Application Technology. The course focuses on moving beyond isolated network layers to designing integrated, resilient systems that function under physical real-world constraints. Building on the heavy networking projects I completed at EPITECH, this class challenged me to build an end-to-end pipeline.
Since I’ve been deep-diving into the Rust programming language and aiming for a career as a video game software engineer, I decided to tailor the final project to my goals: building a modular, competitive Matchmaking System.
The Architecture & The “Why”
The original project requirement was straightforward: generate data from an edge node, transmit it under network constraints to a server, process it with an algorithm to make a decision, and display the entire pipeline on a live web dashboard.
I wanted to build something I could directly apply to a competitive platform game I’m currently developing. Instead of just fetching static sensor data, I designed a system with complex state management and multiple concurrent connections.
The Scope: Players connect to the server via TCP sockets. From there, they can create lobbies, join existing ones, and search for a match. Once the system finds a match, players must confirm. When all players confirm, a game instance is created. For simplicity in this iteration, I focused on 1v1 matches and simulated the game outcomes. Once a match concludes, the server updates the players’ Elo rankings (acting as the system’s “decision/intelligence” logic) and sets them back to an idle state.
The Real Challenge: Network Constraints & Edge Cases
The core philosophy of this project wasn’t just making a system work locally, but designing one that survives bad network conditions and handles inevitable crashes. This is where the headache and the real learning began.
To meet the course requirements, I simulated intentional constraints like packet loss, delays, and random client disconnects. Handling these edge cases forced me to completely rethink my logic. For example, if a player disconnects while a match confirmation is pending, I had to implement strict timeouts so the queue wouldn’t block infinitely for the remaining players. Managing these state changes concurrently across all players in Rust meant navigating its strict borrowing rules. The biggest pain was avoiding deadlocks to ensure states were updated properly across all active threads. Finding good documentation for specific Rust network libraries was tough, but overcoming these concurrency issues was incredibly rewarding.
Live dashboard
To visualize the pipeline, I built a live, interactive dashboard using Next.js and Shadcn UI, a stack I’m using for “Griffon”, my final project at EPITECH.
I created a custom hook that connects directly to the Rust backend, stores the incoming state data, and dynamically refreshes the UI. Once a clean provider is set, Its really easy and convenient to ask AI agent; to make the component to display real-time matchmaking queues, server health, and ranking adjustments.
Reflection
I’m really satisfied with how this project turned out. It’s not perfect, but I learned a massive amount about how network constraints directly affect user experience variables like queue times and matchmaking success rates.
It also opened my eyes to the sheer complexity of scaling. I was successfully handling tens to hundreds of simulated players, but scaling this to a massive competitive game means thinking about load balancing across multiple servers, redirecting connections, and synchronizing global states.
My technical foundations from EPITECH gave me the tools to build the software, but this ICT class provided the macroscopic, system-level perspective I needed to design the architecture properly. I can definitely see myself tweaking this Elo algorithm and implementing this Rust server architecture into my future game releases.
Try It
The code is on GitHub: MatchmakingSystem