A Rust API on three servers
lessons learned

The architecture, in three roles

The three servers are connected by a private network, and administration goes through a bastion: no admin port is publicly open.

Why Rust for the API

The service must stay up without supervision. A single binary, with no virtual machine to embed, starts in milliseconds and consumes almost nothing at idle. Type checking catches at compile time an entire category of bugs that, elsewhere, only appear in production.

The cost is real: compilation is slow, the learning curve is steep, and local recruitment for this language is difficult. We accepted it for a service that must not go down, not as a default choice.

The integration pipeline, from commit to production

Each push triggers three steps: tests, compilation, deployment. The pipeline shows three successes or it blocks. At launch, external measurements showed latency around eighteen milliseconds on the health route, with continuous availability since going live.

What we would do differently

• Write tests before public deployment the temptation to open early to show the service always costs a week of debt.
• Pin base image versions a silent environment update broke a compilation on a Friday evening.
• Document restoration, not just backup a backup that has never been restored is not a backup, it is a file.

The language was never the point. What made the difference was role isolation, deployment automation, and backups we know how to restore.