Performance Without Compromise
Most gateways make you choose between features and speed. Ferrum Edge was built on the premise that you shouldn't have to choose. Here's why.
The Lock-Free Advantage
Traditional API gateways protect shared config with a mutex (or RwLock). Every request must acquire that lock to read routing tables, plugin configs, and upstream lists. Under high concurrency, threads pile up waiting — even for a read-only operation.
Ferrum Edge uses ArcSwap for config storage — a lock-free, wait-free atomic pointer swap. Request threads perform a single atomic load to get a reference-counted pointer to the current config. No locking, no waiting, no contention.
When config updates arrive, the update thread creates a new config object and atomically swaps the pointer. In-flight requests finish with the old config; new requests immediately see the new one. Zero downtime. Zero mutex. Zero drama.
Traditional Gateway (Mutex)
Request → acquire RwLock → read config → release lock → proxy. Under load, threads queue waiting for the lock. At 10,000 concurrent requests, this becomes a thundering herd problem.
Ferrum Edge (ArcSwap)
Request → atomic load (Arc pointer) → read config → proxy. No lock acquired, no contention possible. All 10,000 concurrent requests proceed simultaneously with zero coordination overhead.
// Config updates (admin/reload thread)
config_store.swap(Arc::new(new_config));
// Request handling (hot path - NO LOCKS)
let config = config_store.load(); // atomic
let route = config.routes.get(&host); // O(1) DashMap
route.plugins.iter().for_each(|p| p.execute(&req));The Numbers Speak for Themselves
Benchmarked on Apple Silicon M-series, 200 concurrent connections, 10-second duration, 64-byte echo payload.
| Protocol | Gateway RPS | Direct RPS | Overhead | Assessment |
|---|---|---|---|---|
| HTTP/1.1 | 102,183 | 209,910 | ~51% | reqwest connection pool with keep-alive |
| HTTP/1.1 + TLS | 101,317 | 209,361 | ~52% | TLS termination at gateway, plain HTTP to backend |
| HTTP/2 | 108,138 | 355,544 | ~70% | hyper-native H2 pool with multiplexing |
| HTTP/3 QUIC | 53,085 | 83,592 | ~37% | QUIC connection pool via quinn |
| gRPC | 68,352 | 205,927 | ~67% | H2 multiplexing + protobuf passthrough |
| TCP Proxy | 108,841 | 214,113 | ~49% | Bidirectional copy, minimal per-byte overhead |
| WebSocket | 103,830 | 207,507 | ~50% | Upgrade overhead amortized over many messages |
Performance That Holds at 30,000 Proxies
Most gateways degrade sharply as config grows. We ran a live multi-tenant simulation — 30k proxies,
each with key_auth + access_control, each with a unique consumer, config loaded live under traffic.
At 30,000 proxies Ferrum Edge was still delivering 42,434 RPS — 86% of its 3k-proxy baseline.
P50 latency barely moved: 1.0ms → 1.1ms. This is possible because every hot-path lookup is O(1) via pre-computed
HashMaps and lock-free ArcSwap reads — the route table, plugin index, and consumer credential index
never block a request thread, no matter how large they grow.
Why Teams Choose Ferrum Edge
Built in Rust
Memory safety without a garbage collector. No buffer overflows, no use-after-free, no null pointer exceptions — enforced by the compiler. This isn't just marketing; it means Ferrum Edge never pauses for GC, never segfaults, and handles adversarial traffic without memory corruption risks.
Lock-Free Hot Path
ArcSwap atomic reads and DashMap concurrent maps mean request threads never block on config access. Under extreme concurrency, this difference is massive — traditional mutex-based gateways see throughput collapse as threads contend. Ferrum Edge scales linearly with CPU cores.
True Multi-Protocol
HTTP/1.1, HTTP/2 with ALPN negotiation, HTTP/3 over QUIC, WebSocket upgrades, gRPC streaming, raw TCP, and UDP — all with optional TLS and DTLS. Most gateways call themselves "multi-protocol" but mean HTTP/1.1 and HTTP/2. Ferrum Edge means every protocol your stack actually uses.
AI/LLM Ready
Four dedicated AI plugins: token metrics tracking, prompt shield for content filtering, request guard for model access control, and token-based rate limiting. Built for the realities of proxying LLM APIs — cost control, abuse prevention, and per-consumer token budgets.
Resilience by Design
Config is cached locally — if your database goes down, Ferrum Edge keeps running with the last known good config. Data Plane instances auto-reconnect to Control Plane after network interruptions. Graceful shutdown drains in-flight requests before exiting. Resilience isn't an afterthought; it's baked in.
Extensible via Custom Plugins
Write your own plugins in Rust. Drop them in the custom_plugins/
directory and they're auto-discovered at build time. The plugin trait gives you
hooks at every stage of the request lifecycle — from connection to response
transformation. No forking, no unsafe FFI.
How Ferrum Edge Fits In
Different gateways serve different needs. Here's an honest look at the landscape.
vs. nginx / Caddy
nginx is battle-tested but C-based with Lua plugins. Caddy is excellent for TLS automation. Ferrum Edge offers Rust-native plugin APIs, native AI/LLM support, Control Plane/Data Plane distribution, and lock-free config updates without process reloads.
vs. Envoy
Envoy is a C++ powerhouse popular in service meshes. It's highly configurable but operationally complex. Ferrum Edge offers simpler operations, Rust memory safety (no C++ footguns), and a built-in plugin system that doesn't require WebAssembly or external processes.
vs. Kong / API Gateways
Kong is a mature Lua-on-nginx gateway with a large plugin marketplace. Ferrum Edge trades the marketplace for built-in quality — 51 production-ready plugins, lock-free performance, and Rust type safety with no dynamic language overhead on the hot path.
Every Protocol, One Gateway
Consolidate your infrastructure. One gateway to handle HTTP APIs, gRPC services, WebSocket connections, and raw TCP/UDP — with or without TLS.
Convinced? Let's Get You Running.
Start with the file-mode quick start — no database needed. Production-ready in minutes.