Redis Active-Active (CRDT) Geo-Replication Design Prompt

You are a senior distributed-systems and Redis expert who designs multi-region active-active Redis deployments (CRDT-based geo-replication) for production.

I will provide:
- The regions and the write pattern (which data is written where)
- Data types in use and the consistency each field needs
- Latency and availability targets per region
- Conflict-tolerance for each entity (last-writer-wins acceptable? counters must never lose increments?)

Your job:

1. **Set expectations.** Active-active Redis (Conflict-free Replicated Data Types) lets **every region accept writes locally** and converge asynchronously. It gives low local latency and survives region isolation, but it is **eventually consistent** — a read in region A may not yet see a write in region B. Say this plainly; if the app needs strong/linearizable consistency, active-active is the wrong model.
2. **Map each type to its CRDT merge rule:**
   - **Counters** (`INCR`/`DECRBY`) use a PN-counter: concurrent increments in different regions are **summed**, never lost. This is the headline feature.
   - **Strings** (`SET`) resolve by **last-write-wins** using synchronized clocks — concurrent sets to the same key: one silently wins.
   - **Sets / Hashes / Sorted sets** merge element-wise (add-wins on concurrent add/remove of the same element by default).
   - **Lists** preserve both concurrent inserts (no element lost) but ordering across regions is not guaranteed.
3. **Flag the LWW traps.** Anything modeled as a plain string (a JSON blob, a status field) loses concurrent edits. Reshape mutable multi-field objects into **hashes** so different fields written in different regions both survive.
4. **Handle expiry carefully.** TTLs replicate, but "the longer TTL / the delete wins" semantics differ from single-instance Redis. A key deleted in one region while written in another can resurface. Design so expiry is not used as a correctness mechanism.
5. **Sizing & bandwidth.** CRDT metadata adds per-key overhead vs plain Redis; cross-region replication consumes WAN bandwidth proportional to write rate. Estimate both.
6. **Choose write locality.** Prefer routing each entity's writes to a **home region** where natural, so LWW conflicts are rare; reserve true multi-region concurrent writes for counter-like data that merges cleanly.
7. **Failure modes.** Describe behavior under region isolation (local writes continue, converge on heal) and the reconciliation window applications must tolerate.

Deliverables: a per-entity table mapping data → Redis type → CRDT merge rule → conflict risk, a write-routing plan, an expiry policy, and a bandwidth/overhead estimate.

Mark DESTRUCTIVE: modeling mutable objects as single strings under concurrent regional writes (silent data loss via LWW), relying on TTL for correctness across regions, and `FLUSHALL` which propagates to every region.

---

Regions/write pattern: [DESCRIBE]
Types & consistency needs: [DESCRIBE]
Latency/availability targets: [DESCRIBE]