How We Built an Ultra-Low Latency Security Proxy in Rust & Python

mmrobeerto-ops — Tue, 04 Aug 2026 13:34:31 +0000

By Roberto (Systems & High-Performance Developer)

In the world of cybersecurity, there is a golden rule: Security that destroys usability will eventually be turned off by the engineers.

When we started building TZANiX Q-Guard, an open-core post-quantum auditing proxy designed to prevent "Harvest Now, Decrypt Later" exfiltration attacks, we hit a massive wall. The proxy needed to intercept network traffic, calculate the Shannon entropy and volumetric anomalies in real-time, and act as a Kill-Switch—all without slowing down legitimate database queries.

Our initial prototype in pure Python was functionally perfect but operationally unacceptable. This is the story of how we rewrote our core mathematical engine in Rust, dropped our network latency by 88.4%, and accidentally built an engine so fast it broke our own firewall.

The Python Bottleneck: Math in the Critical Path
Q-Guard acts as a sidecar proxy. It sits between the client and the database, mapping every connection into a 4D topological model (Tesseract Model):

X (Source): IP and Port.
Y (Magnitude): Volume of data.
Z (Entropy): Mathematical noise injected.
T (Time): Latency.
To detect an exfiltration attack, the proxy applies an Average True Range (ATR) algorithm over the historical
Y
Y magnitude of every IP. In pure Python, evaluating these multi-dimensional tensors in a tight for loop across thousands of concurrent connections triggered the dreaded Global Interpreter Lock (GIL).

The result? A baseline latency of 50.56 ms and a capped throughput of a few hundred requests per second. For High-Frequency Trading (HFT) or enterprise APIs, adding 50ms of lag per database query is a dealbreaker.

Enter Rust: The TZANiX Core Engine
We needed C++ speeds, but we wanted memory safety to prevent segmentation faults in a security product. We chose Rust and integrated it directly into Python using PyO3 and Maturin.

Instead of doing the math in Python, we built tzanix-core. We aggregated the incoming network packets into a batch (the Swarm Buffer) and passed a massive 3D tensor (PyReadwriteArray3 via ndarray) to Rust.

Using Rust's rayon library, we parallelized the calculation across all available CPU cores with a single line of code:

rust

// From single-thread to multi-thread instantly
datos.par_iter_mut().for_each(|drone| {
// Heavy Tesseract math here
});
The synthetic benchmarks were staggering: We scaled from ~83 million events per second in pure Python to ~389 million events per second in Rust. But synthetic benchmarks don't pay the server bills. We needed an End-to-End network test.

The Unforeseen Challenge: When Your Engine is Too Fast
We set up an extreme I/O benchmark simulating hundreds of concurrent TCP connections hitting the proxy. We expected the Rust engine to crush Python.

When the results came back, the latency had indeed dropped to 5 ms... but the throughput (Requests per Second) had plummeted to single digits. What happened?

We had run into a classic networking phenomenon: TCP Coalescing. Because the Rust engine was evaluating the stream almost instantly, the OS networking stack began merging multiple 1 KB payloads from the stress-tester into single 4 KB or 8 KB chunks.

Our dynamic ATR Kill-Switch saw a client that normally requested 1 KB suddenly request 8 KB in a single read. The algorithm interpreted this as a massive Volumetric Exfiltration Spike (a false positive) and ruthlessly severed the connections. Our engine was so fast that it triggered its own security alarms.

The Fix: Smart Thresholds & The Flush Latch
To solve this, we implemented two industrial patterns:

Minimum Anomaly Threshold: We calibrated the proxy to ignore mathematical volatility if the absolute payload size was below 8 KB.
The Flush Latch with Padding: We set a hard rule to flush the Swarm Buffer if it reached 50 packets OR if 2 milliseconds elapsed. To prevent the Rust fixed-window algorithm from crashing on tiny arrays (e.g., < 20 events), we dynamically padded the remaining slots.
The Final Results: Enterprise-Grade Stability
With the architecture stabilized, we subjected Q-Guard to three extreme infrastructure tests:

Anti-Slowloris (FD Exhaustion): We attacked the proxy with 50 zombie connections. The asynchronous Idle Timeout purged them exactly at 5.0 seconds.
Dirty Network (Jitter & Fragmentation): We injected 50ms of artificial latency and fragmented the TCP payloads. The Rust padding reassembled the math flawlessly without a single dropped byte.
The Memory Soak Test: The ultimate test of the PyO3 bridge. We blasted the server continuously. The RAM climbed initially as the TCP buffers and HashMaps warmed up, but then flatlined mathematically at 42.2 MB. Zero memory leaks.
Metric Legacy (Pure Python) TZANiX Swarm (Rust) Business Impact
Average Latency 50.56 ms 5.87 ms 📉 88.4% Reduction
Max Latency Spikes 199.48 ms 20.31 ms 🛡️ High Availability
Server RAM Usage 31.89 MB 31.77 MB ⚡ Static Consumption
Conclusion
You don't have to rewrite your entire backend in Rust to get enterprise performance. By profiling your Python application, isolating the heaviest mathematical or I/O-bound bottlenecks, and offloading only that specific layer to a Rust core, you get the best of both worlds: Python's rapid development speed and Rust's raw, memory-safe power.

TZANiX Q-Guard and the tzanix-core engine are open-source. Check them out on [GitHub] and [PyPI].

DEV Community: mmrobeerto-ops

How We Built an Ultra-Low Latency Security Proxy in Rust & Python