14 days ago
Environment:
Platform: Railway, multi-region deployment (4 replicas: US West, US East, EU West, Southeast Asia)
App: Next.js 16
CMS: Sanity, triggering revalidation via webhook on content edit
Issue:
I'm running 4 replicas of the same Next.js service across different Railway regions to serve users with low latency. Content is managed in Sanity, and edits trigger a revalidation request to my Next.js app (using revalidatePath/revalidateTag via a webhook handler).
The problem: Railway's load balancer routes that single revalidation webhook request to only one of the 4 replicas. Since Next.js's ISR cache is per-instance (in-memory / on-disk per container, not shared), only the replica that received the webhook actually revalidates its cache. The other 3 replicas keep serving stale content until they happen to restart or their cache naturally expires.
As a result, users in different regions see different content depending on which replica handles their request.
What I'm trying to understand:
Is there a way on Railway to broadcast a single incoming request to all replicas of a service (instead of load-balancing to just one)?
Does Railway expose any internal mechanism (private networking, replica discovery/DNS, internal service list) that would let me fan out the revalidation call myself from the webhook handler to each replica's internal address?
Is there a recommended pattern for multi-region Next.js deployments on Railway where ISR/on-demand revalidation needs to stay in sync across all instances?
Any guidance on Railway's replica networking model for this kind of use case would be appreciated — happy to share more logs/config if useful.
2 Replies
14 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 14 days ago
14 days ago
You can configure a custom cache handler for so the cache is shared across replicas: https://nextjs.org/docs/app/guides/self-hosting#caching-and-isr
14 days ago
Railway can't broadcast a request to all replicas, and there's no way to address individual replicas either.
The real issue is that Next.js ISR cache is local to each container by default. When running multiple instances, the default file-system cache is per-instance, and on-demand revalidation only invalidates the instance that receives the call. This isn't a Railway limitation — it'd break the same way on Kubernetes, Fly, anywhere. Next.js
Next.js has a cacheHandler config that lets you swap the filesystem cache for Redis. A shared Redis cache ensures all instances read from and write to the same cache, and on-demand revalidation takes effect across all instances immediately. Optimizely
Your Sanity webhook keeps working exactly as-is — it calls revalidatePath()/revalidateTag(), which writes the invalidation to Redis, and all replicas pick it up.
The one tradeoff: if Redis is in US West and your SEA replica reads from it, that's 100-200ms of cross-region latency per cache read. Upstash with global read replicas solves that cleanly. Or keep a small local LRU with a short TTL (say 60s) and accept that CMS edits take up to a minute to propagate everywhere — usually fine for content sites.