Cache Tags and Revalidation After a Mutation

Specify cache tags for read-heavy pages and the revalidation that runs when the data changes. A user who edits their own record should not see a stale page. FRAMEWORK [NEXT.JS APP ROUTER] Pages: [LIST] Mutations: [LIST] Who can see the data: [PUBLIC | PER USER | PER ORG] DELIVER 1) The tag scheme: a tag per entity id and a tag per list. Show the fetch or the data helper that sets them. Include the tenant in the tag so one org cannot share another's cache entry. Say that out loud. 2) The mutation: after the write commits, revalidate the entity tag and the list tag. Show where this must not run if the write failed. 3) Private data: why a user-specific page should not sit in a shared cache, and the pattern instead (no store, or a cache key that includes the user and is not public). 4) A stale-while-revalidate note for the public page only, with a time I can edit. 5) A manual purge path for support, protected like an admin action. Do not revalidatePath("/") as the default. Do not cache personalized HTML on a shared CDN without a Vary or a private cache control, and show the header.