When one region stops being enough, the standard options are a rewrite, a global database migration, or eventual consistency and the bugs that come with it. Swytch makes the cache layer active-active instead. Every region writes locally. Your application code does not change.
# macOS / Linux (Homebrew)
brew tap swytchdb/tap
brew install swytchDocker: ghcr.io/swytchdb/swytch
Point each region’s clients at their local Swytch nodes. Writes commit in-region and propagate outward. When two regions write the same key at the same moment, they converge to the same value — deterministically, not last-writer-wins.
No primary region. No failover runbook. No read-replica asterisk in the architecture diagram.
# eu-west
r = redis.Redis(host="swytch.eu-west.internal")
r.set("cart:1042", eu_payload) # commits locally
# us-east — same key, same moment
r = redis.Redis(host="swytch.us-east.internal")
r.set("cart:1042", us_payload) # commits locally
# both regions converge to the same valueSame client library. Same commands. The only thing that changed is the hostname.
Active-active is not a feature you configure. It is how every Swytch node works, all the time.
São Paulo writes in São Paulo. Frankfurt writes in Frankfurt. No region is far from the primary, because there is no primary.
Per prefix, you choose: block the minority for strict consistency (the default), or keep both sides writing and reconcile deterministically when the link heals. Either way — no conflict queue, no last-writer-wins.
No Sentinel. No primary election. No 3am promotion. A node that went away rejoins and catches up. That’s the whole procedure.
Self-host it free under AGPL. Point your existing client at it. See what active-active feels like when it’s the default.
Not deploying today? Drop your address and we’ll send the migration guide.