Role: Product design, system architecture, API development, frontend implementation, workflow modeling, and testing infrastructure
Stack: Python, FastAPI, Punq, MongoDB, MontyDB, React, TypeScript, Socket.IO, Redis, Playwright, LiveKit, and Docker
Status: Deployed and ready for controlled production pilots. Backup processes are still recommended for mission-critical events while the platform is battle-tested in real venues.
Before we get into the guts of Athletica, I should probably explain why it exists.
Anyone who has spent a Saturday inside a wrestling gym knows that tournaments are organized chaos. You have matches running across several mats, table workers trying to keep everything moving, coaches asking where their athletes are supposed to be, parents refreshing brackets, and an event director attempting to hold the whole thing together.
Then someone changes a bracket.
Or a mat falls behind.
Or the venue internet decides that today is the perfect day to stop working.
Competition software is responsible for keeping all of those people looking at the same version of the event. A single match result may affect the mat queue, the bracket, team scores, athlete records, public results, livestream graphics, and what match is called next.
That sounds like a normal data-management problem until the first whistle blows.
Athletica is my attempt to build a competition-management platform around the reality of running martial arts events. It supports folkstyle wrestling first, with the architecture being developed to eventually support freestyle, Greco-Roman, Brazilian Jiu-Jitsu, Judo, and other grappling sports.
I did not build Athletica to be another digital bracket sheet. The long-term goal is for it to compete with platforms such as TrackWrestling and FloArena while providing something I believe tournament software desperately needs: the ability to keep operating locally when venue internet is unreliable.
Only a software engineer would look at a stressful Saturday in a gym and decide the answer was several backend services, two web applications, a synchronization engine, and a multi-user tournament simulator.
More Than a Tournament CRUD App
At its simplest, Athletica manages events, teams, athletes, divisions, brackets, matches, results, and team scores.
But those resources are only the foundation.
The administrative application gives event staff the tools to configure and operate an event. Staff can create divisions, register teams and athletes, generate brackets, assign matches to mats, manage queues, score bouts, review results, export data, contact teams, manage users, and monitor recordings.
The public application serves wrestlers, coaches, families, and fans. It provides event discovery, live queues, brackets, results, match views, athlete profiles, favorites, notifications, and account-linked athlete pages.
Table workers sit between those two experiences. They need a focused scorekeeping workflow that lets them control the match in front of them without accidentally interfering with another table.
Each audience is interacting with the same tournament, but they do not need the same application or the same level of control. Separating those experiences allowed me to keep the administrative tools powerful while keeping the public experience easier to navigate.
Designing for Bad Internet
Most modern software assumes the cloud is always available.
That assumption works reasonably well in an office, but wrestling events are often held in large gyms, field houses, convention centers, and older school buildings. Reliable Wi-Fi is not guaranteed, cellular reception can be inconsistent, and hundreds of spectators may be competing for the same connection.
An active event should not stop because a request cannot reach a cloud server.
Athletica is designed to support both cloud and on-premises installations. In an on-premises setup, the event can operate against a local server and file-backed database within the venue. The cloud installation remains useful for remote spectators, backups, public visibility, and services that need to exist outside the building, but the active competition does not have to depend entirely on it.
The backend uses a repository abstraction that can communicate with MongoDB in the cloud or a local MontyDB-backed data store. This lets the domain and application services operate without needing separate implementations for every deployment model.
When synchronization is enabled, local writes create outbox events. Those events are published to a separate Node.js and Socket.IO synchronization service, which distributes updates between installations.
The synchronization layer includes authenticated server connections, event and tenant isolation, acknowledgements, optional Redis scaling, versioned writes, and snapshot tooling for recovery and reconciliation.
The objective is straightforward: allow the event to continue locally and give the system the information it needs to bring each installation back together.
The implementation for that model exists, but this is also one of the areas that needs the most real-world validation. Simulated failures and automated testing can prove that the pieces communicate correctly. They cannot completely recreate a packed gym with questionable networking, several active mats, tired table workers, and an event director who does not have time to restart Docker containers.
That part requires real events.
The Technical Guts
The core Athletica API is written in Python using FastAPI, Pydantic, Punq for dependency injection, and repository and unit-of-work patterns around the data layer.
The server owns most of the competition domain:
- Events, divisions, teams, and athletes
- Bracket generation and bout numbering
- Mat assignment and queue management
- Match scoring and progression
- Individual tournaments and dual meets
- Dual-tournament pools and placement workflows
- Team scoring and tie-breakers
- Public event and result APIs
- User accounts and athlete-profile linking
- Billing and event-hosting entitlements
- Notifications, exports, and team communication
- Video rooms, recordings, and overlays
- Installation registration and synchronization status
The administrative and public clients are React and TypeScript applications. The admin client is built for event staff and table workers, while the public client is built for fans, coaches, athletes, and families.
Live updates are delivered through WebSockets and the Socket.IO synchronization layer. Redis can be added when the sync service needs to scale across multiple instances, but it is not required for a smaller installation.
Video responsibilities are handled separately. Athletica integrates with LiveKit for rooms and stream access, while a lightweight Python recording agent starts and stops local recording jobs, supervises recording workers, and persists job information.
Breaking these responsibilities into separate applications adds deployment complexity, but it also prevents the core tournament API from becoming responsible for everything. A problem in a recording worker should not take down scorekeeping, and a public-client deployment should not require restarting the event server.
Configuring the Competition Instead of Hardcoding It
Wrestling events rarely follow one universal format.
An individual tournament may use double elimination, single elimination, round robin, or pools. A dual meet has different scoring and progression requirements than an individual bracket. A dual tournament may begin with pools before advancing teams into placement brackets.
Even within folkstyle wrestling, an event may change period lengths, weight classes, placement rules, team scoring, match limits, or tie-breaker behavior.
Athletica uses an EventConfig system to keep these decisions out of one enormous conditional statement. Configuration documents describe the sport, event type, match rules, scoring rules, advancement behavior, placements, and tie-breakers.
Factories and strategies then select the correct bracket-generation, scheduling, progression, and scoring behavior.
The strongest support today is for folkstyle wrestling. Individual single-elimination, double-elimination, round-robin, and dual-meet workflows have concrete implementations and automated coverage. Dual-tournament infrastructure is substantial but still being hardened around more complex pools, advancement paths, and edge cases.
Freestyle and Greco-Roman are represented in the domain and roadmap, but I would not call them fully supported yet. BJJ and Judo are farther down the road and will require more than changing a few scoring values. Each sport has its own competition structure, terminology, timing, progression rules, and edge cases.
The architecture makes that expansion possible. It does not make it free.
A Match Result Is Never Just a Match Result
One of the more interesting parts of building Athletica has been modeling what happens after a table worker submits a result.
The obvious changes are recording the score, winner, loser, and completion status. But the system may also need to update the competitors’ last-match times, calculate required rest, refill an open mat position, update a dual-meet score, advance a bracket, recalculate standings, notify connected clients, and update the public event view.
There is also the question of who is allowed to change the match.
Athletica uses leases to reduce the chance of two table workers controlling the same bout at once. Protected writes can also include an expected document version, allowing the API to reject updates made against stale data instead of quietly overwriting a newer result.
These tools help detect and prevent conflicting updates. They do not magically resolve every distributed conflict, especially when multiple installations reconnect after operating separately. Snapshot and reconciliation infrastructure exists, but broader conflict-recovery behavior still needs to be proven under real venue conditions.
That distinction is important. Detecting that two people disagree is much easier than deciding which person was right.
Testing a Tournament Through the UI
Traditional unit and API tests are useful, but a tournament is a multi-user system.
An API test can confirm that a match result was stored. It cannot, by itself, prove that a table worker submitted that result through the real interface, that a fan saw the match change, and that another fan saw the bout disappear from the active queue.
To test those interactions, I built the Athletica Simulator.
The simulator uses Playwright to run deterministic browser-driven tournament scenarios. It models several actors, including an administrator, a table worker, and multiple fans, each operating in a separate browser context.
A typical scenario may have an administrator prepare a seeded event, two fans watch the queue, and a table worker open and complete a match. While the worker scores the bout, one fan follows the live match and another watches for the queue to transition.
The simulator then checks whether the views remained coherent:
- Did the worker complete the intended match?
- Did the fan open the same match?
- Did the queue change when the match started?
- Did the completed match leave the active queue?
- Were the results and standings available afterward?
- Did the scenario complete through the intended user interface?
The last question became important enough that the simulator tracks fidelity. A scenario completed entirely through the UI receives no degradation. Recovery paths and direct API fallbacks reduce the fidelity score.
That prevents a test from claiming success simply because it forced the database into the expected final state.
Each run can produce JSON and HTML reports, screenshots, timelines, and diagnostics. The simulator does not replace load testing or a real production tournament, but it gives me much more confidence than isolated API tests alone.
Video, Recording, and Broadcast Support
Athletica also includes infrastructure for livestreaming and match recording.
The backend can create LiveKit rooms and issue publishing or viewing tokens. The administrative client includes tools for video devices, room viewing, overlay previews, and recordings. A separate recording agent manages local jobs and recording processes.
Keeping the recorder separate was intentional. Video processing can be resource intensive, and failures should remain isolated from core event operations.
The pieces for streams, recordings, and custom overlays are implemented, but the entire production broadcast workflow is still being validated. I am especially interested in connecting live scoring data to overlays so spectators can see the clock, score, competitors, and match information without a production operator manually maintaining it.
Eventually, the same match record that powers brackets and results should also connect directly to its livestream, recording, and athlete profiles.
Where Is Athletica Now?
Athletica is technically deployed and what I would call pseudo-production ready.
People can use it today, provided they coordinate with me for setup. The strongest workflows have extensive unit tests, API tests, browser tests, and scripted simulations behind them.
What it does not have yet is a long history of running full, mission-critical events in unpredictable real-world conditions.
For that reason, I consider Athletica ready for controlled production pilots. I encourage testing it with actual competitions, but I also recommend keeping a backup process available until the platform has been battle-tested across different venue sizes, networks, event formats, and operating teams.
That may not be the most exciting marketing statement, but competition software has to earn trust. A tournament director should not be asked to gamble an entire event on a developer saying, “It passed on my machine.”
What Is Ahead?
There is still plenty left to build and validate.
The next milestones include:
- Supporting more complex folkstyle configurations
- Hardening dual-tournament pools and progression
- Completing riding-time workflows
- Expanding freestyle and Greco-Roman support
- Running full production events at realistic scale
- Testing local operation and synchronization under real venue failures
- Connecting scoring more deeply with livestreams and recordings
- Improving athlete profiles, notifications, analytics, and reporting
- Continuing toward configurable support for BJJ and Judo
The immediate goal is not to support every martial art or every tournament format. It is to make the folkstyle foundation reliable, configurable, and trustworthy enough to support real events.
Athletica has grown far beyond the bracket application I originally had in mind. It has become an exploration of distributed systems, real-time applications, local infrastructure, domain modeling, video processing, and multi-user testing—all built around a sport I have participated in and coached for most of my life.
There is still a large gap between competing with TrackWrestling or Flo and simply saying that is the goal. But the foundation is here, the important workflows are taking shape, and I am looking forward to putting the platform through the only test that ultimately matters: running real competitions.
That is enough wrestling software talk for today.
— Tre