Local and Distributed Keys
Keep frequently used state beside the application, and share keys when multiple workloads need them. Your client keeps using ordinary Redis commands.
Only distributed keys pay distributed latency.
Swytch subscribes to keys through application use. A key used by one node can stay local to that workload. When another node accesses it, that node establishes a subscription and retrieves the state it needs.
There is no separate DISTRIBUTE step in this workflow. A key name such as local:foo does not enforce locality or
isolation. Separate instances or clusters are appropriate when data must never be shared.
| Operation | Cost to plan for |
|---|---|
| Access to resident local state | Local process work, memory, and client transport |
| First access on another node | Discovery, subscription, and fetching state |
| Access after eviction | Rehydration from a holder or configured storage tier, if available |
| Transaction involving shared keys | Coordination with the relevant subscribers; distant subscribers add latency |
| Non-transactional write | Propagation and command-specific work; it does not use the transaction commit barrier |
A localhost client connection does not make a distributed transaction local. The geographic spread of the key’s subscribers matters more than the count of unrelated nodes.
Use workload-specific keys for rebuildable data that no other application needs. Use shared keys for sessions, counters, or queues that several workers access. Key names help organize that intent; access patterns determine subscriptions.
Do not treat extra replicas as guaranteed copies of every key. Do not treat a successful health check as proof that a key is present.
For failure behavior, see disconnected operation. For the deeper consistency model, see architecture.