LatencyGuard

Inspiration

A market-data change can preserve every test result while quietly adding work to the processing path. LatencyGuard was built to catch that kind of regression before it reaches production and to make any proposed fix easy for a person to verify.

What it does

LatencyGuard maintains a validated BTC/USD order book from Kraken’s public market-data feed. It records raw market events and replays a fixed dataset so a merge request can be compared with its accepted baseline under the same workload. The performance gate checks allocation operations, allocated bytes, and reallocations. When it confirms a regression, GitLab Duo can investigate and prepare a replacement merge request with fresh validation evidence. A human makes the final approval decision.

How we built it

The core is a synchronous Rust processing path: decode a Kraken payload, validate it, update the order book, and verify its checksum. Network and recording work stay outside that measured path. Exact decimal values preserve the formatting Kraken requires for checksum calculation.

The gate verifies replay correctness before measuring performance. It compares baseline and candidate revisions in alternating rounds on a registered Linux runner and publishes a report identifying the workload, revisions, measurements, and verdict.

Challenges and lessons

Reliable measurement was the hardest part. Runner timing varied too much to support a trustworthy latency verdict, so the current gate makes decisions from repeatable allocation counts; latency and throughput remain diagnostic. We also had to keep performance work from weakening market-data correctness: a failed checksum makes the book unavailable until a fresh snapshot restores it.

The result is a supervised workflow that connects a reproducible regression, a proposed correction, and the evidence needed to review it.

Built With

• axum
• gitlab-ci/cd
• gitlab-duo
• kraken-websocket-api
• linux
• prometheus
• rust
• serde
• tokio
• websockets