LibreBoard

Inspiration

Our aim for this project was to create a leaderboard that was easy to use, fast, efficient, and stable. We envision this being used at events to track competition between thousands of potential users, while remaining blazingly fast.

What it does

LibreBoard has a very simple API. Users can add their scores to the leaderboard, replace their past scores and remove their active score if they are no longer participating. They can also see the top of the leaderboard, track stats about the competition and view the history of all entries or entries for a specific user. Admins also have access to performance statistics and various settings to customize their board.

How we built it

We settled on using Axum in the Rust ecosystem to handle our REST API and PostgreSQL for our database.

Axum provides us with a powerful runtime leveraging the tokio crate to create a multi-threaded asynchronous environment capable of providing service to many users concurrently. Rust provides a strong type system that catches many bugs before they reach production. By modeling our database within the rust type system we are able to provide a simple, ergonomic, and strong interface to developers.

PostgreSQL, along with the sqlx crate provide a reliable, fast, and scalable database. With sqlx, all queries can easily be refactored to include compile-time checks against a live database. Coupled with our strongly typed models, this stack is capable of catching nearly all common bugs before any runtime is reached.

To package and serve our stack, we leveraged Docker and Docker Compose. With a provided makefile, deploying the service is as simple as running make run. The setup includes incremental builds, saving precious development time often lost in compiled languages, management of associated containers, and easy admin password resets.

Challenges we ran into

The first challenge that we faced as a team was the use of an unfamiliar stack. As individuals, some members of our team had used the Rust programming language before, nobody had use every part of our chosen stack. Learning the tools we chose took some time, and with the 24 hour submission deadline, time was in limited supply. Through collaboration, careful reading, and prioritization, we pushed through and delivered.

Another challenge came from project management. In the early hours of the competition we began to rush and ended up having to adjust the scope of our project several times. This also cost us valuable time and led to some compromises needing to be made. In the future, we plan to spend much more time deliberately laying out the scope of our project to avoid this.

Accomplishments that we're proud of

The most important accomplishment in this project in our eyes is the speed we have achieved. We created a small test script to model a typical usage scenario. With 60 seconds of 200 concurrent connections modeling 2000 users hitting mostly write-heavy endpoints, we saw a top speed of 19 thousand requests handled per second. Over the test period this resulted in over 1 million requests with a 100% success rate.

This amazing speed is a result of both our choice of language and framework and the design of our API and database. We separated our important data -- such as live leaderboard scores -- from less important data like history and configuration. This allowed us to focus on our hottest targets for optimization, leveraging techniques such as request coalescence and write batching.

What we learned

We learned a huge amount in both technical skills and project management skills. Our struggles through a new tech stack taught us how to work together to solve new problems and how to use our available resources to the best of our abilities. The tight time constraint and initial uncertainty also stressed our teamwork and project management skills to ensure all deliverables were completed and done well.

What's next for LibreBoard

Next up for LibreBoard, we plan on increasing our already great performance. We expect this to include expanding our local caching ability to get responses back to clients even faster, increasing scalability, allowing more users to enjoy this project and introducing redundancy where it's needed. We also would like to add compile-time checking of SQL queries through sqlx to eliminate yet another class of common bugs.

As we move forward with LibreBoard, we also plan on keeping up what has been working for us. This includes our strongly typed models and clean separation. Keeping these ideas core to the project will continue to allow it to perform as well as it does now.