Scaling

Scale the application and let each new Pod receive its own Swytch sidecar. Keep the same local Redis endpoint.

From one Pod to several

After the quickstart, add another replica:

kubectl -n swytch-demo scale deployment/example-app --replicas=2
kubectl -n swytch-demo rollout status deployment/example-app
kubectl -n swytch-demo get pods -l app=example-app

Each Pod has its own memory budget. The profile’s headless Service supplies peer addresses. Allow UDP 7379 between participating Pods.

To check a shared key, select two Pod names from that output. Write through one application’s container, then read through the other:

kubectl -n swytch-demo exec POD_A -c app -- redis-cli SET shared:greeting hello
kubectl -n swytch-demo exec POD_B -c app -- redis-cli GET shared:greeting

The second read establishes use of that key on the other node. A successful test says that these Pods can share this key; it does not establish redundancy for every key.

Across nodes, clusters, and regions

Kubernetes placement controls where Pods run. Spreading Pods across nodes protects against losing all processes on one machine, but data still needs a surviving holder or storage tier.

For multiple clusters, install an operator in each cluster and plan reachable peer addresses, shared identity, and discovery. Kubernetes Pod IPs and cluster-local DNS are not automatically reachable from another cluster. See multi-cluster and multi-region topology.

The programming model stays the same as you grow. Measure memory, first-read cost, and shared-operation latency at the intended topology; more nodes alone do not prove capacity for thousands of workloads.