Fixing ISR Revalidation Across Kubernetes Replicas on strapi.io

In addressing the challenge of ensuring consistent Incremental Static Regeneration (ISR) across multiple Kubernetes replicas, a Strapi team encountered issues with the Next.js revalidation mechanism. The problem stemmed from the ISR cache being cleared only on the specific pod where the revalidation request was processed, leading to stale content being served by other pods. This situation was exacerbated by routing behaviors of the load balancer and CDN, causing editors to lose trust in the revalidation process. Initial attempts to solve the issue using shared caches and experimental Next.js features were unsuccessful due to architectural constraints and bugs. The successful solution involved implementing a Redis Pub/Sub system to broadcast revalidation requests to all pods, ensuring each pod cleared its own cache. This was achieved by having each pod make an internal HTTP request to trigger cache invalidation, despite Redis's absence at initial deployment. The team's approach allowed for graceful degradation, maintaining functionality even if Redis became unavailable, and highlighted the importance of adapting solutions to framework limitations. Future updates in Next.js are expected to simplify such implementations, but the current setup has stabilized the content delivery process and restored trust among content editors.