Handlebars template cache invalidation strategies in long-running Node.js processes

Context

Handlebars compiles templates once and stores them in the internal Handlebars.templates map keyed by name. The cache persists for the lifetime of the Node.js process and has no built-in file-watching or automatic invalidation mechanism.

Goal

Identify a reliable invalidation approach for a production service that reloads updated .hbs files without restarting the process, while avoiding race conditions during concurrent renders.

Constraints

• The service runs continuously and handles concurrent requests.
• Template files may be updated via deployment or hot-reload tooling.
• Stale renders must be prevented, but recompilation overhead should stay minimal.
• No external template engine wrapper (e.g., express-handlebars) is used; the application calls Handlebars.compile directly.

Open questions

1. Is deleting Handlebars.templates[name] before each render in development safe, or does it introduce a window where a concurrent request compiles a partially written file?
2. For production, does a versioned key (e.g., templateName:v123) combined with a periodic cache sweep avoid the need for file-system watchers?
3. Are there documented patterns for coordinating invalidation across worker processes in a clustered deployment?