Slack Bot Multi-Region Failover & High-Availability Prompt

You are a resilience-focused SRE who runs Slack bots that page on-call and
trigger deploys, and must keep them up through a full regional failure.

I will provide:
- The bot's responsibilities (alerts, ChatOps commands, approvals, deploys)
- Current topology (Socket Mode or HTTP Events, regions, datastore)
- RTO/RPO targets and the blast radius of a duplicate action
- Coordination primitives available (Redis, DynamoDB, etcd, Consul)

Your job:

1. **Choose a model** — active/standby (one region processes, other warm) vs
   active/active (both process, dedup downstream). Give the trade-offs against
   the RTO/RPO and the duplicate-action risk.

2. **Idempotency** — dedup every inbound event on `event_id` (and
   `client_msg_id` for messages, `trigger_id` for interactivity) via a shared
   store with TTL; show the check-and-set that guarantees exactly-once side
   effects even under Slack's 3x retry.

3. **Single-writer coordination** — a distributed lease (e.g. Redis SETNX with
   TTL, or DynamoDB conditional write) so only one region holds the "active"
   role for side-effecting actions; define lease renewal, expiry, and takeover.

4. **Socket Mode failover** — how multiple Socket Mode connections behave (Slack
   load-balances across them), how to run a standby that connects only on
   promotion, and the HTTP-endpoint equivalent (health-checked regional URLs
   behind a failover DNS / global LB).

5. **State & continuity** — replicate the datastore cross-region, handle
   in-flight modals/approvals during cutover, and reconcile actions that were
   mid-flight when the primary died.

6. **Failover testing** — a game-day plan: kill the primary region, assert no
   duplicate posts/deploys, measure actual RTO, and verify auto-failback.

Output: (a) model recommendation with rationale, (b) idempotency design with
the CAS snippet, (c) lease/lock protocol with timings, (d) Socket Mode + HTTP
failover topology, (e) state-replication and in-flight reconciliation plan,
(f) game-day runbook and success metrics.

Correctness beats availability for side-effecting actions: prefer a brief gap
over a duplicate deploy or a double page.