Architecting an L7 proxy in Go versus Rust

WHAT THIS TESTS It checks whether you can act as a tech lead and justify a language choice for a latency-critical, high-concurrency networked service using concrete engineering trade-offs, not slogans.

A GOOD ANSWER COVERS Memory management: Go's garbage collector frees developers from manual lifetimes but introduces stop-the-world phases and allocation pressure that show up as p99 and p999 latency spikes under heavy connection churn. Rust's ownership model has no runtime collector, giving deterministic deallocation, smaller and more predictable memory footprints, and no GC-induced tail latency, at the price of fighting the borrow checker. Concurrency: Go's goroutines are cheap and you write straightforward blocking code, with the runtime multiplexing onto OS threads; Rust uses async/await futures driven by an executor such as Tokio, avoiding thread-per-connection costs but exposing Pin, lifetimes, and Send bounds. Error handling: Go's (T, error) is explicit and simple; Rust's Result plus ? gives compiler-enforced handling and rich typed errors.

COMMON WRONG ANSWERS Saying Rust is always faster, or that Go cannot handle high throughput. Ignoring team familiarity and time-to-market. Forgetting that GC tuning (GOGC, GOMEMLIMIT) can mitigate but not eliminate pauses.

LIKELY FOLLOW-UPS How would you measure and budget tail latency? Where would zero-copy buffer handling matter? How does ecosystem maturity (net/http versus hyper/tower) affect the decision?

ONE CONCRETE EXAMPLE For a proxy fronting tens of thousands of long-lived TLS connections with a strict 10ms p99 SLA, Rust with Tokio and hyper avoids GC pauses and keeps per-connection memory low, which directly protects the tail. If instead the priority is shipping a feature-rich proxy quickly with a team already fluent in Go, Go with a tuned GC and goroutine-per-connection is the pragmatic choice, accepting a few extra milliseconds at the tail in exchange for velocity.