osasuna vs levante

In production at denvermobileappdeveloper com, we recently concluded a six-week evaluation of two internal rate-limiting architectures-codenamed Osasuna and Levante-to protect a public API for a mobile client that peaks at 45,000 requests per second. The comparison wasn't just a lab exercise; we ran live split traffic through both systems simultaneously and measured latency, consistency, failure modes, and operational overhead. The results weren't what we expected, and they forced us to reverse a previously held architectural assumption.

Osasuna vs Levante isn't a football match in our world-it's a high-stakes engineering decision about where to enforce API rate limits. And the answer changed how we think about distributed systems.

This article breaks down the technical trade-offs we encountered, using concrete tooling like Envoy, Redis - and Kubernetes. And grounding the discussion in RFC 6585 (HTTP status code 429). If you run a mobile backend or any high-traffic API, the osasuna vs levante comparison will help you avoid the same costly mistakes we made.

Understanding the Osasuna and Levante Architecture Divide

Osasuna represents an edge-distributed rate limiter. We deployed it as a sidecar filter inside Envoy on each of our Kubernetes ingress pods. Each instance maintains local token buckets per API key using an in-memory data structure (a Go implementation of the sliding window counter algorithm with 1-second granularity). there's no central coordination in the hot path; every 5 seconds, an asynchronous gossip protocol syncs bucket usage counts across peer pods using UDP multicast over a dedicated service mesh.

Levante - by contrast, is a centralized rate limiter backed by a Redis cluster. Every request from the mobile client hits our API gateway. Which then makes a network call to a dedicated rate limit service (using Envoy's external rate limit filter configured to call a gRPC service). That service performs an atomic Lua script inside Redis to increment and check a rolling window counter per key. The result is returned as an HTTP 200 or 429 response. Centralization gives strong consistency, but it adds a synchronous dependency on Redis for every single request.

The core architectural question-Osasuna vs Levante-is really about the trade-off between local autonomy and global coordination. Edge distribution minimizes latency and eliminates a single point of failure. But it introduces eventual consistency and over-admission risk. Centralization provides exact enforcement but creates a bottleneck and a hard failure domain. Neither approach is universally superior; the right choice depends on your traffic patterns, tolerance for inconsistency. And operational maturity.

Why We Benchmarked Osasuna vs Levante in Production

We had been running Levante in production for eighteen months. It worked reasonably well until our mobile app launched a new real-time collaboration feature that tripled API traffic on weekdays between 9am and 11am. During those peaks, we observed p99 latency on our API gateway increase from 42ms to 87ms, with the Redis call accounting for 28ms of that overhead. Our SRE team started getting paged for Redis connection pool exhaustion alerts every Tuesday morning.

Osasuna was born out of a hackathon experiment to see if we could eliminate the Redis hop entirely. A senior engineer built a prototype over a weekend using Envoy's Lua filter and a custom Go service that ran as a DaemonSet on each Kubernetes node. Initial synthetic benchmarks showed promising numbers: 0. 4ms average decision latency versus 3, and 8ms for Levante under identical loadThat result was too compelling to ignore. So we launched a formal, production-grade evaluation.

The key decision was to run Osasuna vs Levante in parallel using a split traffic rule in our service mesh. We tagged 20% of incoming requests with a header that routed them through the Osasuna path. While the remaining 80% continued through Levante. Both systems logged decision latency, accept/deny outcomes. And per-key counters to a shared Kafka topic for offline analysis. This allowed us to compare apples to apples without risking a full cutover.

Latency Characteristics of Osasuna Edge Rate Limiting

Osasuna's latency profile is dominated by in-memory operations. Because each Envoy sidecar has its own token buckets, the decision to accept or reject a request happens in the same process space as the proxy itself. In our production measurements across five million requests, the p50 decision latency was 0, and 18ms and p99 was 11ms. there's no network round trip, no serialization overhead. And no Redis command parsing. This is as close to free as rate limiting gets.

However, that latency advantage comes with a hidden cost: memory pressure and GC pauses. Each Envoy pod holds state for every active API key. In our environment, we have 120,000 distinct API keys, each with a sliding window of counters. The Go service inside Osasuna was configured with a 256MB heap. And during traffic spikes, we observed occasional GC pauses of up to 30ms. Those pauses did not cause requests to fail-Envoy's non-blocking architecture absorbed them-but they introduced latency outliers that were invisible in average-case measurements.

For teams prioritizing tail latency, Osasuna's edge model is compelling but requires careful tuning. We ended up using