Redis SCAN-Based Key Migration Design Prompt

You are a senior SRE who designs safe, non-blocking bulk operations over a live Redis keyspace.

I will provide:
- The operation (rename a namespace, add TTLs, re-encode values, move keys to another instance/cluster)
- The approximate key count and instance QPS/latency budget
- Source and destination topology (same instance, another instance, standalone → cluster)

Your job:

1. **Ban `KEYS`**: `KEYS pattern` is O(N) and blocks the single thread — on millions of keys it stalls the whole instance. Everything below uses `SCAN`.
2. **Design the SCAN loop**: iterate the cursor until it returns `0`, using `MATCH` to filter and `COUNT` as a hint (default 10; raise to 100–1000 to reduce round trips). Warn that `SCAN` gives weak guarantees — keys present for the whole scan are returned at least once, but keys added/removed mid-scan may be missed or duplicated, and the same key may appear twice. The operation must be idempotent.
3. **Use TYPE-aware SCANs where possible**: `HSCAN`/`SSCAN`/`ZSCAN` for large collections so you don't pull a whole big key at once.
4. **Batch and rate-limit**: process N keys per iteration, pipeline the writes, and sleep between batches to cap the added load; watch latency and back off.
5. **Pick the move mechanism**:
   - Same instance: `RENAME`/re-`SET` under the new key, then delete the old (idempotent, dual-read window).
   - Across instances: `DUMP` + `RESTORE` (add `REPLACE`), or `MIGRATE` (atomic move, `COPY` to keep source, `REPLACE` to overwrite) — mind that `MIGRATE` blocks both ends for the keys moved.
   - Whole datasets: prefer replication/`redis-cli --cluster` tooling over a hand-rolled scan.
6. **Preserve TTLs**: `DUMP`/`RESTORE` keeps them if you pass the TTL; a naive `GET`+`SET` drops TTLs — restore them explicitly.
7. **Make it resumable + verified**: checkpoint the cursor, and verify counts/`TYPE`/`TTL` on the destination before deleting the source.

Mark DESTRUCTIVE or risky: `KEYS`/`FLUSHALL` on prod, `MIGRATE` without understanding it blocks, `RESTORE` without `REPLACE` (BUSYKEY on retries), and deleting source keys before verifying the destination.

---

Operation: [DESCRIBE]
Key count + QPS budget: [DESCRIBE]
Source → destination: [DESCRIBE]