Feature Request: Unified Server-Initiated Data Revalidation for All Active Clients

[m3l0-d3v]

Goals

The goal of this feature request is to introduce a unified, server-initiated mechanism in Next.js that triggers immediate data revalidation across all currently connected clients. This capability should allow the server to broadcast cache invalidation events that proactively prompt active sessions to refetch data, re-execute cached functions, or refresh server-rendered components. The objective is to ensure real-time data consistency, reduce reliance on custom synchronization layers, and provide a standardized approach for applications requiring up-to-date, synchronized information across multiple concurrent users.

Non-Goals

No response

Background

Next.js provides several powerful caching and revalidation features—such as revalidateTag, revalidatePath, and ISR—that ensure future requests receive fresh data. However, these mechanisms are limited to server-side invalidation and do not affect clients that are already connected and currently consuming cached data. As a result, developers building applications that require synchronized data across active sessions (e.g., inventories, order management, dashboards, collaborative tools) must create and maintain additional infrastructure, such as WebSockets, polling mechanisms, or custom broadcast channels. This adds operational complexity and often results in inconsistent data across clients.

Proposal

Introduce a native Next.js API that allows the server to broadcast a revalidation signal to all active clients, instructing them to refresh any data associated with invalidated tags or resources. This mechanism would function similarly to revalidateTag, but its impact would extend to existing active sessions, ensuring that real-time updates propagate immediately across all connected clients.

However, introducing entirely new functions or API surfaces would not be necessary. This capability could be achieved by evolving the existing revalidation API through a second options parameter. This object could include a broadcast: boolean property, indicating that the revalidation event should be propagated to all currently connected clients. Additionally, this approach would integrate naturally with the existing expire property available in version 16, maintaining consistency with the current design while avoiding additional complexity.

Illustrative example:

await revalidateTag("products", { broadcast: true, expire: 0 });

This lightweight yet powerful extension would enable a unified and native revalidation flow without requiring external real-time infrastructure. It would provide a standardized and reliable mechanism for synchronizing data across all connected clients, significantly improving state consistency in mission-critical applications.