Redis Endpoint

Redis endpoints connect Eve to Redis-compatible systems such as Redis OSS, Redis Cloud, Valkey, ElastiCache, MemoryDB, Azure Cache for Redis, KeyDB, and Dragonfly-compatible deployments.

Redis is the most complete public migration surface today. The guided migration workflow supports Redis-compatible source and target endpoints, interlays, compatibility checks, SCAN/DUMP/RESTORE data movement, TTL preservation, test runs, error-key export, and rollback.

What Eve Uses Redis Endpoints For

Redis endpoints can be used in three ways:

• Direct endpoint API calls through /api/v1/endpoints/{endpoint}/read and /write.
• Interlay listeners that proxy live Redis client traffic.
• Redis migration workflows where the endpoint is a source, target, mirror target, or compatibility-check target.

For migration work, create separate endpoint records for the source, the target, and any additional mirror targets. Do not model multiple Redis databases or multiple HA targets as one endpoint.

Basic Endpoint Shape

Use explicit read and write connections when the endpoint is part of a migration:

{
  "endpoint": "redis-source",
  "kind": "redis",
  "config": {
    "read_conn": {
      "host": "redis-source.internal",
      "port": 6379,
      "tls": false,
      "protocol_version": 2
    },
    "write_conn": {
      "host": "redis-source.internal",
      "port": 6379,
      "tls": false,
      "protocol_version": 2
    },
    "connection_pool": {
      "multiplexed_connections": 1
    }
  },
  "description": "Current Redis source"
}

Create it:

curl -sS -X POST "$EDEN/endpoints" \
  -H "$AUTH_HEADER" \
  -H "Content-Type: application/json" \
  -d '{
    "endpoint": "redis-source",
    "kind": "redis",
    "config": {
      "read_conn": {
        "host": "redis-source.internal",
        "port": 6379,
        "tls": false,
        "protocol_version": 2
      },
      "write_conn": {
        "host": "redis-source.internal",
        "port": 6379,
        "tls": false,
        "protocol_version": 2
      },
      "connection_pool": {
        "multiplexed_connections": 1
      }
    },
    "description": "Current Redis source"
  }'

Credentials Shape

Redis endpoint config supports a newer target plus per-role credentials shape:

{
  "endpoint": "redis-target",
  "kind": "redis",
  "config": {
    "target": {
      "host": "redis-target.internal",
      "port": 6380,
      "tls": true,
      "protocol_version": 2
    },
    "read_credentials": {
      "username": "reader",
      "password": "<read-password>"
    },
    "write_credentials": {
      "username": "writer",
      "password": "<write-password>"
    },
    "admin_credentials": {
      "username": "admin",
      "password": "<admin-password>"
    },
    "connection_pool": {
      "multiplexed_connections": 1
    }
  }
}

Do not mix target with read_conn and write_conn in one endpoint config. Keep the shape unambiguous.

Fields

Migration Requirements

Before using a Redis endpoint in a migration:

• Source should be Redis 5 or newer for the current DUMP/RESTORE path.
• Target should be the same Redis major version or newer.
• Source and target should have compatible module availability when keys use module-specific data types.
• The migration operator must have permission to read source keys, write target keys, run compatibility checks, and inspect errors.
• If preserving TTL, source must allow PTTL and target must allow RESTORE.
• If using cluster mode, interlay listener topology must match the exposed source cluster topology.

Interlay Setup

Applications should connect to an interlay instead of the source during migration:

curl -sS -X POST "$EDEN/interlays" \
  -H "$AUTH_HEADER" \
  -H "Content-Type: application/json" \
  -d '{
    "id": "redis-live-interlay",
    "endpoint": "redis-source",
    "port": 6200,
    "settings": {
      "max_concurrent_connections": 512
    }
  }'

Start it:

curl -sS -X POST "$EDEN/interlays/redis-live-interlay/start" \
  -H "$AUTH_HEADER"

Client connection string:

redis://<eden-host>:6200/

Compatibility Checks

Redis compatibility checks can report:

• Source version is below the supported generation.
• DUMP/RESTORE version mismatch between source and target.
• Source and target modules differ.
• Source or target ACL user cannot run required commands.
• Cluster mode differs between source and target.
• Interlay listener count does not match source cluster node exposure.

Resolve blocking issues before approval. If an issue is non-blocking and accepted by the migration owner, acknowledge it with notes through the compatibility API.

Data Movement

The standard Redis path scans source keys and restores them into the target:

1. SCAN discovers keys without blocking the source.
2. DUMP reads serialized values.
3. PTTL captures remaining TTL.
4. RESTORE writes serialized values to the target.
5. Conflict policy decides what to do if a target key already exists.
6. Error keys are exported for retry or manual review.

Supported conflict policies include:

Write Consistency Policies

Choose the policy before approval. For most initial production migrations, SourceAuthoritative is the conservative default because source remains the trusted system until commit.

Commands To Treat Carefully

During live migrations, be deliberate with commands that are stateful, connection-affine, or non-deterministic:

• MULTI, EXEC, and WATCH need connection affinity and can be restricted depending on routing mode.
• Pub/Sub subscriber connections are long-lived and should usually move directly to the target during migration.
• Lua scripts should be deterministic and idempotent if mirrored or dual-written.
• Very short TTL keys may naturally expire at slightly different times across endpoints.
• SELECT database usage should be verified; most production Redis deployments use database 0.

Runbook

1. Create source and target Redis endpoints.
2. Create and start an interlay for source traffic.
3. Point application clients at the interlay.
4. Create a guided Redis workflow run.
5. Submit setup with source, target, strategy, data movement mode, conflict policy, write consistency, and TTL preservation.
6. Subscribe to workflow events.
7. Prepare the workflow.
8. Review compatibility, analysis, and test output.
9. Approve execution.
10. Monitor live metrics and error keys.
11. Toggle or increase traffic according to strategy.
12. Complete only after target acceptance.
13. Keep source available through the agreed rollback window.

Related

• Migrations
• Migration APIs
• Interlays