Sub-100µs Redis Protocol Interception

Tags: announcement, release

Eden v0.5.0 introduces a complete RESP (Redis Serialization Protocol) encoder and decoder in Rust. This unlocks wire-protocol interception, real-time command mutation, and live migration between Redis instances—all with under 100 microseconds of added latency per operation.

We showed this off at Redis Released in San Francisco, demonstrating live migrations of application traffic between Redis databases with zero code changes and zero downtime. The audience reaction? Let's just say people were impressed.

The Challenge: Don't Slow Down Redis

Redis is fast. A typical GET completes in 100-200µs. Any proxy sitting in the request path needs to be nearly invisible, or it becomes the bottleneck that defeats the whole purpose of using Redis.

We set an aggressive target: under 100µs total overhead, including parsing, rule evaluation, and re-encoding.

The result is a zero-copy, streaming RESP parser that processes most commands in under 200 nanoseconds. That's fast enough that your application won't notice we're there.

Why Wire Protocol Interception?

Traditional database migration approaches require changing your application code:

# Before migration
redis_client = Redis(host="old-redis.example.com")

# During migration (code change required)
redis_client = MigrationProxy(
    old=Redis(host="old-redis.example.com"),
    new=Redis(host="new-redis.example.com"),
)

# After migration (another code change)
redis_client = Redis(host="new-redis.example.com")

This means coordinated deployments, testing cycles, and rollback complexity. For organizations with hundreds of services, this can turn into a multi-month project involving every team.

With wire protocol interception, your application just connects to Eden instead of Redis directly. Eden handles all the migration magic transparently:

# Works unchanged during the entire migration
redis_client = Redis(host="eden-proxy.example.com")

No code changes. No deployments. No herding cats across teams.

How RESP Works (The Short Version)

Redis uses RESP (REdis Serialization Protocol) for all client-server communication. It's deceptively simple—text-based with length prefixes—but the devil is in the details when you need to handle millions of operations per second.

Eden's parser reads messages directly from the network buffer without copying data around. This matters because every copy costs time, and those microseconds add up fast at scale.

We also support both RESP2 (Redis 2.x-6.x) and RESP3 (Redis 7.x+), auto-detecting which version your client speaks from the HELLO command.

How Interception Works

Eden sits transparently between your application and Redis:

┌─────────────┐     ┌─────────────────────────────┐     ┌─────────────┐
│ Application │────▶│         Eden Proxy          │────▶│   Redis     │
└─────────────┘     │  ┌─────┐ ┌─────┐ ┌───────┐ │     └─────────────┘
                    │  │Parse│→│Rules│→│Encode │ │
                    │  └─────┘ └─────┘ └───────┘ │
                    └─────────────────────────────┘
                              < 100µs

Once your traffic flows through Eden, you can do some pretty powerful things:

Route by key pattern — Send cache: keys to one Redis instance, session: to another.

Transform commands — Add key prefixes, encrypt values at rest, or modify commands on the fly.

Dual-write for migrations — Write to both old and new databases simultaneously during a migration.

Capture traffic — Log a sample of commands for analysis and debugging.

Where Do the Microseconds Go?

We obsessed over latency. Here's the breakdown:

| What | Time |

|------|------|

| TCP receive/send | 20-40µs (kernel overhead) |

| RESP parse | 15-30µs |

| Rule evaluation | 5-10µs |

| RESP encode | 10-20µs |

| Total Eden overhead | 50-100µs |

For context, a typical Redis GET takes 100-200µs. Eden adds less than 50% overhead for same-AZ deployments. For cross-region traffic (where network latency is 20-100ms), Eden's overhead is a rounding error.

The Demo That Got Everyone's Attention

At Redis Released in San Francisco, we showed a live migration:

• 10,000 operations per second of live application traffic
• 1 million keys to migrate
• Zero downtime during the entire process
• Zero application changes required

Here's what happened:

1. Application running against old Redis at 10K ops/sec
2. Point DNS to Eden proxy (instant, no restart needed)
3. Start migration via Eden's API
4. Watch the progress dashboard update in real-time
5. Complete cutover when migration finishes
6. Verify data integrity with checksums

The results:

• Total migration time: 7 seconds
• Application errors: 0
• Latency increase: <10µs
• Data integrity: 100% match

Not bad for a million keys while handling 10,000 operations per second.

Try It Yourself

# eden.yaml
proxy:
  listen: 0.0.0.0:6379

  targets:
    - name: redis-old
      host: old-redis.example.com:6379
    - name: redis-new
      host: new-redis.example.com:6379

  routing:
    default: redis-old

  migration:
    enabled: true
    source: redis-old
    destination: redis-new

eden proxy start

Your application connects to Eden on port 6379—same port as Redis, same protocol. From your application's perspective, it's just talking to Redis. It has no idea a migration is happening behind the scenes.

Learn more in our docs →