Share Selected State Across Workloads

Share a session, counter, or work queue across application instances while keeping each client’s connection local.

Run sidecars with a common peer identity and reachable discovery. Use the two-Pod example to verify a write through one Pod can be read through another.

Choose keys by the scope of the work: session:123 for a session, jobs:images for an image queue. Subscriptions follow access, so every workload need not subscribe to every key.

First access can fetch remote state. Transactions on shared keys involve their subscribers. A globally shared key can add cross-region latency even though every application connects to localhost.

Use hashes for related fields, counters and sessions for common application patterns, and streams when consumers need acknowledgement and recovery.

Extra nodes are not automatic backups. Choose tiering separately from how many application replicas you run.