Concurrency and Asynchronous I/O: Performance Comparison Between Go, Rust, and.NET Runtimes for High-Throughput Gateways

The Challenge of High-Throughput Gateways and the I/O Model

Building API gateways and reverse proxies capable of handling hundreds of thousands of simultaneous connections requires a deep understanding of how hardware interacts with software. Asynchronous input and output, technically known as async I/O, allows a program to send a request to read data from a disk or network and continue executing other tasks while waiting for the response, rather than freezing the execution thread waiting for the file to arrive. In practice, this means the server does not waste precious resources sitting idle watching the clock. When dealing with high-throughput systems, every millisecond of delay and every kilobyte of allocated memory per connection multiply rapidly, making the choice of development ecosystem a critical business decision.

Historically, systems relied on models based on dedicated threads for each incoming connection. However, the operating system consumes a significant amount of memory for each created thread, severely limiting scalability. To circumvent this limitation, modern environments have adopted low-level event notification primitives, such as epoll on Linux and kqueue on macOS, combined with runtimes that manage thousands of logical tasks multiplexed over a small pool of real threads. This conceptual leap transformed the way we design network infrastructure, pushing modern engineering toward ecosystems that prioritize lightweight concurrency and efficient event queue management.

Go: Simple Concurrency with Goroutines and Channels

The Go language, developed by Google, approaches concurrency through goroutines, which are concurrently executed functions managed by the language's own runtime. A goroutine initially consumes only a few kilobytes of memory on the stack, allowing an application to keep hundreds of thousands of them active simultaneously without overloading the operating system. The internal scheduler of the language intelligently distributes these tasks among a fixed number of operating system threads corresponding to the number of available processing cores. In practice, programming in Go feels like executing traditional synchronous code, while the runtime takes care of the complexity of suspending and resuming operations behind the scenes.

For safe communication between these goroutines, Go uses channels, structures that act like pipelines where data is passed from one side to the other in a synchronized manner. Although this model facilitates writing clean and readable code, it brings some important trade-offs. The garbage collector, the mechanism responsible for cleaning up memory no longer in use, can introduce small, unpredictable pauses known as stop-the-world latency. In extreme high-throughput gateway scenarios, these pauses, although millimetric, can affect the tail of the latency distribution, requiring fine-tuning and a deep understanding of the runtime's internal behavior.

Rust: Total Memory Control and Zero-Cost Abstractions

Rust adopts a completely different philosophy by eliminating the traditional garbage collector in favor of a strict compile-time system of variable borrowing and ownership. This means the compiler rigorously tracks who owns each piece of memory and how long it can be accessed, preventing concurrency bugs even before the code runs. In practice, Rust offers what we call zero-cost abstractions, meaning advanced high-level programming features are translated into machine code as efficient as that written manually in C or C++. For gateways requiring absolute latency predictability and minimal resource consumption, Rust emerges as a formidable choice.

Rust's asynchronous ecosystem revolves around futures, which represent values yet to be computed, coupled with powerful runtimes like Tokio. Tokio acts as a high-performance engine that manages task scheduling and the I/O event loop in an extremely optimized way. However, this freedom and power come with a steep learning curve. The developer must deal directly with complex concepts of lifetime management and safe multi-threaded concurrency. The price paid for the absence of a garbage collector is the requirement for much greater conceptual rigor during the development of data structures and application flow control.

.NET: Ecosystem Maturity and Kestrel Performance

The .NET ecosystem, driven by recent evolutions in C# and the .NET Core runtime, has undergone an impressive performance transformation, becoming a heavyweight contender in high-throughput scenarios. The Kestrel web server, built into .NET, was engineered from the ground up to take full advantage of the operating system's native asynchronous I/O through constructs like async and await. In practice, this allows the code to look linear and sequential, while the compiler transforms the function into an efficient state machine that releases the thread to serve other requests while waiting for network or database responses.

Additionally, .NET features a highly optimized generational garbage collector and zero-allocation data structures like Span and Memory, which avoid unnecessary data copies in memory. Although traditionally associated with heavy enterprise applications, modern .NET consumes little memory and delivers throughput rates comparable to lower-level compiled languages in many gateway scenarios. The ecosystem's great asset lies in its rich standard library, integrated diagnostic tools, and ease of maintenance, allowing engineering teams to deliver robust systems in a fraction of the time required by other technologies.

Evaluation Criteria and Benchmarking Workload

To fairly compare the behavior of these three ecosystems in a real-world gateway scenario, we established a laboratory environment simulating HTTP/1.1 and gRPC traffic under high concurrency. The gateway acts as a simple reverse proxy that validates authentication tokens, applies rate limits, and routes traffic to simulated backend services. We used distributed load generation tools to gradually increase the number of active connections from one thousand to five hundred thousand simultaneous connections, measuring crucial metrics such as resident memory usage, request throughput per second, and latency at higher percentiles like P99.

Initial results reveal fascinating dynamics regarding the behavior of each runtime under severe stress. Go demonstrated the best balance between code simplicity and initial setup ease, maintaining stable throughput with moderate memory consumption. Rust stood out for its minimal memory footprint and total absence of latency spikes caused by garbage collection pauses, though it required considerable engineering effort to structure the asynchronous code correctly. .NET pleasantly surprised by delivering throughput performance very close to Rust's, combined with superior instrumentation and telemetry ease provided by the platform's native tools.

Comparative Table of Runtimes for Gateways

The table below summarizes the key trade-offs observed in benchmarking tests, comparing the three ecosystems across fundamental dimensions for high-throughput gateway architecture.

Final Considerations on Technological Choice

Choosing between Go, Rust, and .NET for building a high-throughput gateway does not have a single universal answer, depending directly on team goals and project operational requirements. If the organization's absolute priority is speed of delivery for clean, readable, and maintainable code with excellent overall performance, Go remains an extremely solid and pragmatic choice. On the other hand, if the project demands maximum hardware efficiency, minimal memory consumption, and relentless latency predictability in environments where every nanosecond counts, investing in Rust's learning curve yields rewarding long-term dividends.

Finally, the .NET ecosystem proves that platform maturity and continuous runtime optimization can directly rival languages traditionally considered lower-level in terms of network performance. The final decision must balance development cost, engineer familiarity with the ecosystem, and the infrastructure constraints of the production environment. Understanding the trade-offs inherent to each concurrency model and asynchronous I/O management is the key to architecting resilient, scalable systems capable of supporting the explosive growth of modern digital traffic.