You own a large Next.js App Router site whose routes are all cached. For each kind of content, how do you decide between a time-based revalidation window and event-driven invalidation, and how do you choose how fine-grained your cache tags should be?

## Start from a budget, not a default The failure mode in large codebases is that every route inherits whatever number the first engineer typed. The useful discipline is to write down, per content type, how stale it may be before someone is misled or annoyed. Legal and pricing copy: near zero. Editorial articles: minutes. Marketing pages: hours. A help centre: a day. That budget is a product decision, and once it exists the technical choice mostly falls out of it. ## The two cost curves The choice between window and event is a choice between two scaling axes. A **time-based window** makes revalidation cost proportional to *traffic*, capped at one regeneration per route per window. It requires no integration and no cooperation from anyone else, and it degrades gracefully — nothing breaks if a system upstream goes quiet. Its ceiling is that it can never be immediate, and pushing the number down to chase freshness multiplies regenerations on exactly the hottest routes. **Event-driven invalidation** makes cost proportional to the *rate of change*. For read-heavy content that changes rarely, that is dramatically cheaper and also immediate. Its price is a dependency: someone must reliably emit the event, the endpoint receiving it must be authenticated and available, and the invalidation must reach every instance serving the app. Every one of those is a way to silently stop refreshing. So the rule of thumb: **windows are cheap to build and expensive to make fresh; events are cheap to make fresh and expensive to make reliable.** Choose by which cost you can afford, and then run both — event as fast path, window as backstop — wherever the content matters. The backstop converts "stale forever because a webhook died" into "stale for at most the window", which is the difference between an incident and a nuisance. ## Designing the tag taxonomy Tags are the interface between the systems that change data and the pages that read it, and they deserve to be designed once rather than invented per feature. - **Entity tags** — `post-42`, `author-7`. The default. They match the granularity of real edits: one document changed, so the pages that read that document refresh. - **Collection tags** — `posts`, `navigation`. For changes whose blast radius genuinely is the whole collection: a new item appearing in a list, a reordering, a global navigation change. - **Avoid a single global tag.** A `content` tag on everything makes each trivial edit invalidate the whole site. Every route then re-renders on its next request, hitting your data sources with a cold-cache burst — a self-inflicted thundering herd triggered by a typo fix. - **Avoid tags nobody invalidates.** The mirror failure is tag proliferation: labels attached at read sites that no change event ever names. They cost nothing at runtime but create false confidence that a page is event-refreshed when only the window is actually keeping it honest. The practical enforcement is that tag strings are derived from one shared module (`postTag(id)`, `collectionTag('posts')`) that both the read path and the invalidation path import. Tags are plain strings with no type checking and no registry; a mismatched literal produces no error anywhere, just a page that quietly never updates. Centralising the construction is the only thing that makes a typo a compile-time problem instead of a support ticket six weeks later. ## Operational commitments that come with the policy A policy is only real if it is observable. At minimum: log every invalidation with its tag and source, alert when a content type's invalidation rate drops to zero for longer than it plausibly should, and track how often regenerations fail. On the deployment side, on-demand invalidation is only correct across multiple instances if they share a cache — that is a platform requirement created by the policy, not an implementation detail, and it belongs in the decision rather than being discovered later. Bulk operations deserve an explicit answer too. A content migration that fires ten thousand webhooks will invalidate a collection tag ten thousand times and then re-render everything at once on the next traffic. Deciding up front whether such imports coalesce, or bypass the webhook and rely on the window, is the difference between a routine migration and a paged incident. ## How to present it A strong answer names the budget as the input, names the two cost curves as the reason for choosing, commits to running both mechanisms together for anything important, and then treats tag granularity as an interface design problem with a failure mode at each extreme. Weak answers pick one mechanism as universally better, or describe tags as free labelling with no cost to getting the size wrong.