We’ve open-sourced Tollgate, a Rust library that checks whether a request may run, calculates its cost and records the charge for billing without I/O on the request path.
I built it for an API where the work itself takes nanoseconds. Each instance spends a fenced lease of units allocated from an account’s central balance, using atomic counters and immutable policy snapshots. A background control plane handles lease refills, policy updates and usage ingestion.
A few parts that may interest Rust developers:
-
Typed charge lifecycle: admission opens a pending charge; execution commits it; dropping the committed guard records usage, including during panic unwinding. Cancellation before execution charges nothing.
-
Optional fast lane: priority accounts can use a protected execution-capacity reserve that best-effort traffic cannot consume. Normal admission and funding rules still apply.
-
Shared backend contract: the in-memory store is the executable specification, and PostgreSQL passes the same scenario suite.
-
Assurance: numbered invariants, mutation testing and Lean proofs of the design. The proof models are mutation-tested too. There is no Lean-to-Rust refinement proof.
Admission measured about 134 ns on an M1 Pro in a Criterion microbenchmark—not an HTTP latency measurement. Crash behavior and the limits of the guarantees are documented.
MIT/Apache-2.0. I’d welcome feedback on the charge lifecycle API, cancellation behavior and the gap between the formal models and Rust implementation.
I’d welcome feedback from people building metered Rust services. Does the pending/committed charge lifecycle fit how you handle request execution and cancellation? What would make Tollgate easier to integrate into your service?