File Server

One major service that we needed to have is our cloud storage service. Each product is filled with features, ranging from checkboxes to dropdowns to color pickers etc., and each feature may only have a few options or several so being able to quickly load the settings you want is necessary. Typically, these can easily be stored as either raw or encrypted json files on the local users machine, and if this user wanted to share their preferred configuration with their friend they can do so by sending that file. As you can imagine a competition forms between people in this community for who has the “best” configuration, who has tweaked their settings to perfection… This entices people to sell their configs, yes people sell json files, usually through a third party service that charges fees and provides no leak protection. This is why we decided to move ours to the cloud, so when a user creates a new config it no longer gets saved on their local machine and instead gets saved onto our system and is linked with their account.

This offers some benefits:

Allows users to share and sell directly within our system which ties into the marketplace.
Storing files on our servers prevents users from directly accessing the file which protects sellers.

Project Structure

[redacted]-cloud
├── Cargo.toml
├── src
│   ├── managers
│   │   ├── ... // Database logic seperated from web logic
│   ├── routes
│   │   ├── ... // Web routes
│   ├── services
│   │   ├── ... // Business logic (error handling, file management, logging etc.)
│   ├── main.rs
├── logs
│   ├── ... // Log files

Given the high frequency of file updates and downloads this service needed to be robust and fast. This is where our good friend(and arch nemesis) Rust comes in. Rust’s crazy speed and overly interruptive memory safety will ensure that this system runs smoothly and has little to no downtime. The framework used for the web server is Axum and the ORM of choice is Diesel. Also considering the need for privacy if a user were to sell, this service needed some extra security features on top of TLS.

This included:

Authentication: JWT authentication with a custom session manager.
Encryption: AES-256 encryption with unique session keys for all transmitted data, as well as an ECDH protocol for key exchange across insecure channels.
Data Integrity: SHA-256 hash verification for all transmitted data.
Rate Limiting: The package “tower” was used to implement rate limiting and ensure fair usage.
Error Handling: A custom error handler was implemented to prevent information leakage.
Logging: Comprehensive logging of all requests and responses as well as internal response time metrics.
Ensured endpoints were secure and only accessible to authorized users and followed the principle of least privilege to minimize potential attack vectors.

Benchmarks

I used Postman to test the service. This was the result after a 10-minute test with 20,320 requests sent to the server.

Total requests sent	Request/second	Avg. response time	Error rate
20,320	33.37	76ms	0%

This result gives us a throughput of 33.86 requests per second with an average response time of 76ms and a 0% error rate. This is a great result and really shows the performance of this service.