Beyond Throughput
Architecture and performance of RouteSphere BonVoyage API Gateway, NGINX (Kong and Tyk) and Envoy
RouteSphere Global | Medium feature article | Results snapshot 3 November 2026
An API gateway evaluation becomes more useful when it shows what a team receives for the resources it commits. Successful traffic, slower requests, memory, CPU consumption and configuration recovery all influence that decision.
At RouteSphere Global, we are building BonVoyage API Gateway around a C++/Seastar data plane and a separate Go control plane. Our post-release replay of v1.0.4 now gives us concrete operating observations to discuss alongside that design. [1, 2]
The results so far are promising in specific areas. At one matched HTTPS/1.1 operating point, BonVoyage recorded lower p95 and p99 latency and lower resident memory than the configured NGINX comparator. NGINX consumed less CPU. Header transformations and HTTP/2 produced different latency trade-offs. These are reasons to evaluate the workload carefully.
We conduct these tests and develop BonVoyage. This article is a RouteSphere engineering and product perspective. Kong and Tyk appear in the architectural discussion only; we have not benchmarked them under this campaign contract. Interim numerical comparisons remain subject to the campaign publication review.
How the five gateway designs differ
Each project makes choices about how requests are owned, how configuration changes reach the traffic path and which operational tools accompany the proxy. Those choices help define an evaluation; they do not determine its winner in advance.
BonVoyage keeps request-scoped routing, policy evaluation, upstream selection and response handling with the owning shard. The separate control plane validates declarative YAML and distributes identified immutable snapshots. It provides ACK/NACK state, activation and rollback primitives; the data plane can continue serving its active snapshot during temporary controller unavailability. [1, 2]
NGINX uses event-driven worker processes. Kong adds its own API gateway functionality and deployment options on an NGINX/OpenResty foundation. A result measured for NGINX OSS therefore cannot be relabelled as Kong performance. [4, 5]
Envoy also keeps accepted connections with one nonblocking worker and makes extensive use of thread-local state. It supports fully static deployments as well as xDS-based configuration. Shared-nothing ideas and nonblocking execution are not exclusive to BonVoyage. [6, 7]
Tyk is implemented in Go. Its documented standalone Gateway requires Redis, while its Dashboard is a separate component. A language, garbage collector or plugin boundary is insufficient evidence of a latency or efficiency disadvantage. Those questions require matched measurements. [8, 9]
Architecture descriptions are summaries, not exhaustive feature parity. Editions and versions affect deployment capabilities. Third-party licenses and trademarks remain subject to their owners’ terms.
What the current replay measures
The release replay first checks installation and functional behaviour, then measures selected operating points. At this snapshot, installation Stage A and the 17-case functional Stage B are complete. Stage C has retained 65 directional attempts: 55 accepted, three duration-rejected, six functional-rejected and one rejected before load by the harness. The 108 figure is the planned Stage C directional matrix, not 108 completed feature tests.
Successful RPS counts the traffic delivered successfully. A fixed offered rate identifies an operating point, so near-equal successful rates do not establish maximum capacity. p95 and p99 are primary tail measurements in this replay; p99.9 is retained as a diagnostic reference.
Average CPU core-equivalents measure consumed CPU time divided by elapsed time. They do not count shards, threads or allocated vCPUs. Lower consumed CPU remains a useful resource observation, including when runtime polling contributes to the difference.
RSS is resident memory observed during the test. It is not total reserved memory, a deployment memory limit or a measurement of every allocator commitment. In particular, the BonVoyage profile has a 12 GiB configured Seastar memory budget. RSS alone cannot establish a smaller infrastructure requirement.
The engineering contract classifies these measurements as shared-VM directional. Its publication authorization remains false; five repetitions are required before a scoped competitive claim is considered. The numerical passages are prepared for that review.
HTTPS baseline results so far
At 480,000 offered requests per second over HTTPS/1.1, BonVoyage and NGINX completed all 28.8 million measurement requests in each scheduled repetition. Across six runs, that is 172.8 million successful requests, with zero recorded errors, timeouts or semantic failures.
BonVoyage recorded 1.004 ms p95 and 13.575 ms p99, compared with NGINX’s 1.232 ms and 34.496 ms. Its resident memory was 601.5 MiB versus 954.4 MiB, and descriptors were 3,884 versus 5,205. Successful rates were effectively equivalent to the completed fixed offer.
Get Johny Nixon S’s stories in your inbox
Join Medium for free to get updates from this writer.
The resource cost is part of the finding. BonVoyage consumed 22.95 average application core-equivalents; NGINX consumed 13.31. NGINX also had the lower p99.9 diagnostic median, 75.568 ms versus 128.673 ms. BonVoyage therefore did not lead every latency percentile or CPU measure.
For an evaluator whose API resembles this baseline, the result makes BonVoyage worth examining for its observed p95/p99 behaviour and RSS. The next step is to test those properties against the team’s own latency budget, resource allocation and traffic pattern. The experiment does not isolate which architectural mechanism caused the difference.
Adding header policy changes the comparison
The next workload checks exact header transformation semantics and measures the resulting traffic. At the same 480,000 offered RPS, both gateways again completed their scheduled three-repetition sets with zero errors or timeouts. Across both products, 172.8 million requests succeeded.
NGINX recorded lower primary latency here: 1.335 ms p95 and 29.711 ms p99, compared with BonVoyage’s 1.367 ms and 31.709 ms. BonVoyage recorded 601.2 MiB RSS versus 956.4 MiB, and 3,943 descriptors versus 5,225. Its consumed CPU was higher: 22.12 versus 13.97 average core-equivalents.
The change in latency ordering matters. It shows that adding work can change the comparison, even when both gateways meet the offered rate and semantic checks. It would be premature to predict that BonVoyage’s compiled snapshots will make every more complex policy faster or widen its observed memory difference.
We treat policy complexity as an evaluation question. Routing predicates, authentication, body handling and connection patterns should each be measured with their own controls before a scaling conclusion is made.
HTTP2 and comparator boundaries
HTTP/2 introduces multiplexing and different connection-lifecycle behaviour. In the completed 120,000 offered-RPS set, all measurement requests succeeded across the six accepted runs. NGINX recorded lower p95/p99 and lower raw CPU consumption; BonVoyage recorded lower RSS and fewer descriptors.
The configurations matter. BonVoyage used a 128-connection upstream pool per shard and 4,096 pending requests per shard. The NGINX HTTP/2 profile used keepalive_requests 10000 and max_fails=0 for the two preflight-verified origins. These workload-aware settings are part of the experiment, not a comparison of product defaults.
At 480,000 offered RPS over HTTP/2, BonVoyage has one accepted repetition, recording 1.436 ms p95 and 13.467 ms p99. The final retained NGINX attempt failed the zero-error gate. The extension stopped without a complete matched three-repetition set. That boundary remains diagnostic and does not establish a comparative capacity claim.
Envoy is not included in those HTTP/2 and header-transformation load sets. In the HTTPS/1.1 baseline, its three runs at 360,000 offered RPS returned the correct responses but exceeded the frozen duration contract. They remain duration-rejected diagnostics; their percentiles are not placed beside accepted results as if they were equivalent observations.
Historical evidence and the next evaluation
Our public performance notebook also contains September 18, 2026 engineering results. In one matched-tail experiment, BonVoyage delivered 574,935 successful RPS against NGINX’s 499,938 RPS while staying within the tested p99.9 reference criterion. The products had different offered rates, CPU consumption and IRQ policies. [3]
That result has a precise scope. It showed approximately 15.00 percent more successful traffic inside that historical tail criterion. At those different offers, BonVoyage had higher p95, 78.441 ms versus 58.048 ms, alongside lower p99/p99.9 and higher CPU consumption. One subsequent BonVoyage repetition at 600,000 offered RPS exceeded the reference tail, so the original 20 percent target remained unmet. Those builds do not establish v1.0.4 performance.
For the current release, the useful picture is already more specific than a single peak-RPS claim: BonVoyage recorded lower primary tails at one HTTPS baseline point, while NGINX recorded lower CPU consumption and lower primary latency in other tested profiles. BonVoyage’s lower RSS and descriptor observations are promising within the measured configurations.
BonVoyage also offers a practical evaluation path: Apache 2.0 Gateway source, self-hosted operation without a required RouteSphere account, and documented configuration tools. Console Free is an optional proprietary companion. Release checksums, signatures, provenance and SBOMs help teams inspect artifact identity; they do not certify security or performance. [1, 10]
Start with one service, the policies it actually needs and explicit acceptance criteria. Measure successful traffic, errors, tail latency, consumed CPU, memory and recovery. The right gateway is the one whose demonstrated behaviour fits that operating requirement.
Explore BonVoyage source and releases
Follow the installation and operating guides
Third-party names identify the products discussed. This RouteSphere-authored analysis implies no endorsement or affiliation. Results are workload-specific observations; sources and detailed metric definitions follow in the reference appendix.
Reference appendix with retained measurements
The tables retain the less favourable metrics alongside the charted findings. They are three-run medians for the stated workload and offered rate. All current accepted sets below record zero unexpected errors, timeouts and semantic failures. D1 binds the engineering register, D2 the immutable comparator contract and D3 the run identities.
