1M+ Ops/Second at the 5G Edge: Cachee MEC Benchmarks

We took the same Cachee instance we benchmarked against ElastiCache and applied its performance characteristics to MEC edge deployment. The numbers tell a clear story: Cachee at the 5G edge unlocks use cases that raw 5G latency alone cannot deliver.

Here are the production benchmark results.

Test Environment

All benchmarks were run on production-grade infrastructure to ensure the numbers reflect real-world MEC deployment conditions:

• Instance: c7i.16xlarge (64 vCPUs, 128 GB RAM, 25 Gbps network)
• Storage: NVMe-backed secondary cache for overflow
• Comparison baseline: Standard Redis/ElastiCache deployment in same environment
• Workload: Mixed read/write patterns representative of 5G edge traffic

Head-to-Head: Cachee vs Traditional Edge Cache

5G Use Case Readiness

Raw 5G latency (the time from device to core network and back) typically lands between 20-50ms for most real-world deployments. Many next-generation use cases need latency far below that threshold. Here is where Cachee MEC changes the equation—and where it does not.

What "Unlocked" Means

Cloud gaming, AR/VR, and Industrial IoT all have latency requirements that 5G alone cannot consistently meet. The 20-50ms typical 5G latency includes backhaul to the core network and round-trip to cloud servers. By caching content and API responses at the MEC edge, Cachee eliminates the cloud round-trip for 94-98% of requests, bringing total latency below the threshold these applications need.

For cloud gaming specifically: a game server might make 50-100 state queries per frame at 60fps. Cachee serves those from L1 in nanoseconds instead of waiting for a 30ms cloud round-trip on each one. The frame budget is 16.7ms. That margin matters.

What "Marginal" Means

V2X (vehicle-to-everything communication) needs sub-10ms latency for safety-critical decisions like collision avoidance. Cachee MEC achieves 8-12ms, which overlaps with the requirement boundary. In optimal conditions (strong signal, low radio congestion), this works. In degraded conditions, it may not. V2X deployments should combine Cachee MEC with URLLC network slicing and direct C-V2X sidelink for safety-critical paths.

Breaking Down the Latency Budget

To understand where Cachee's savings come from, here is a latency budget comparison for a typical cloud gaming request:

  Standard 5G Path (no MEC caching)
  ===================================
  Radio (UE → gNodeB):        ~4 ms
  Backhaul (gNodeB → Core):   ~3 ms
  Core Network (UPF → IGW):   ~2 ms
  Internet (IGW → Cloud):    ~15 ms
  Cloud Processing:              ~5 ms
  Return Path:                  ~21 ms
  ───────────────────────────────────
  Total:                        ~50 ms

  Cachee MEC Path (cache hit)
  ===================================
  Radio (UE → gNodeB):        ~4 ms
  UPF Steering to MEC:          ~3 ms
  Cachee AI + L1 Hit:          ~0.5 ms
  Return Path:                  ~3 ms
  ───────────────────────────────────
  Total:                       ~10.5 ms

  Savings:                     ~39.5 ms (79% reduction)

The savings come from eliminating three segments: core network traversal, internet transit, and cloud processing. For 94-98% of requests, those segments simply do not exist.

Capacity: 1M+ Ops/Second Per Node

A single Cachee MEC node on a c7i.16xlarge handles over 1 million operations per second. This is 10x the throughput of a comparable Redis deployment in the same environment.

The capacity advantage comes from three architectural decisions:

• In-process L1 cache — No network hop, no serialization overhead. A hash table lookup in the same process that handles the request.
• Write-behind batching — SET operations return immediately. Background workers batch and pipeline writes to persistent storage.
• AI-driven eviction — The prediction engine knows which keys will be accessed next, so eviction decisions are nearly optimal. No wasted cache capacity on cold data.

For carrier MEC deployments serving millions of concurrent 5G subscribers, this means fewer edge nodes to deploy and manage. A typical metro area MEC site with 3-5 Cachee nodes can handle 3-5 million ops/second—sufficient for hundreds of thousands of concurrent users.

Operational Advantages

The sub-30-second deployment time is particularly important for MEC environments. Carriers need to roll out edge services across hundreds or thousands of sites. A 15-minute manual deployment per site across 500 sites is 125 hours of engineering time. Cachee's container-based deployment with automated orchestration reduces that to minutes.

What These Benchmarks Do Not Cover

Transparency matters. Here is what we are not claiming:

• Radio latency improvements: Cachee does not reduce the ~4ms air interface latency. That is determined by 5G NR scheduling and radio conditions.
• URLLC guarantees: Cachee provides best-effort caching, not deterministic latency bounds. Applications requiring hard real-time guarantees (remote surgery, safety-critical V2X) need URLLC at the radio layer.
• 100% cache hit rate at MEC: Our ElastiCache benchmark achieved 100% hit rate on a stable key set. Real MEC traffic is more dynamic. We report 94-98% as the realistic range for 5G edge workloads.
• All content types: Cachee excels at cacheable content (API responses, static assets, game state, video segments). Non-cacheable real-time streams (live video ingest, WebRTC signaling) pass through to origin.

Next Steps

These benchmarks represent Cachee deployed on general-purpose compute instances. Carrier MEC environments often have access to specialized hardware (SmartNICs, DPUs, persistent memory) that can push performance further. We are actively benchmarking on these platforms and will publish results as they become available.

For carriers evaluating MEC caching solutions: the combination of 1M+ ops/second throughput, sub-nanosecond L1 latency, AI-driven 94-98% hit rates, and sub-30-second deployment gives Cachee a unique position in the 5G edge stack. The use case readiness table above shows exactly which revenue-generating services become viable with this performance profile.