Question presented to candidate: "We run Next.js on Kubernetes with four replicas behind a load balancer. Editors say a published article sometimes shows the old version, depending on the refresh, and after deploys some users get 'Failed to find Server Action'. What is going on, and how should multi-instance self-hosting be set up?"
What a strong answer should cover:
- By default the ISR and data cache lives on each instance's disk and memory, so
revalidatePathorrevalidateTagon one replica leaves the others stale. - A custom
cacheHandler(andcacheHandlersfor'use cache') backed by a shared store, withcacheMaxMemorySize: 0, plus tag invalidation shared across instances. - Build once and run the same artifact everywhere: separate builds get different build IDs, Server Action IDs and encryption keys.
deploymentIdfor version skew during rolling deploys (asset?dpl=, deployment headers, hard reload on mismatch);generateBuildIdwhen you must rebuild per environment;NEXT_SERVER_ACTIONS_ENCRYPTION_KEYpinned.- Operational pieces: a reverse proxy with buffering disabled for streaming, graceful shutdown, and a CDN that respects
Cache-Control.
Clarifying questions expected:
- "Does each pod run
next build, or is one image deployed?" β it decides whether IDs and keys can match. - "Is there a shared store available, like Redis?" β it is the basis for a shared cache.
Code / implementation expected: Yes β a next.config with cacheHandler and deploymentId, and a sketch of the shared handler.