Caching Strategy for Large Next.js E-commerce Site with OpenNext on Cloudflare

[fxmb]

We’re running a large e-commerce site with around 1.5M pages that are frequently updated. Our goal is to implement a caching strategy that works across builds, using OpenNext on Cloudflare.

Here’s the approach we’ve come up with:

1. Build step
   During the build, we upload all static assets (i.e. _next/...) to an R2 bucket, namespaced by the build ID.

2. Cache miss
   When a page request results in a cache miss, we generate the page, store it in our KV cache along with the current build ID, and return it to the user.

3. Cache hit
   If the page is found in the cache, we check the stored build ID:

   • If the build ID matches the current build, we serve the cached page immediately.
   • If the build ID is from a previous build, we still serve the cached page but also trigger a background revalidation so that the next request gets an updated version.
     This gives us a balance between freshness and performance.

4. Static chunks issue
   The main complication is with static Next.js chunks.

   • Example: A user requests a page generated with an old build. The HTML is cached and returned. The client then fetches the corresponding JS chunks for that HTML version. We need to ensure we return the old chunks from R2 (based on the build ID), otherwise the page breaks.

---

Questions

• Does this overall approach make sense?
• How maintainable do you think it is at scale?
• Are there any potential gotchas we should be aware of?
• It feels odd that Next.js doesn’t provide a built-in way to cache pages externally (e.g. in KV) across builds, returning cached results immediately and revalidating only when needed. Are we missing something here?

Any thoughts, feedback, or pointers would be much appreciated!

[hyattc1]

Yeah this setup makes sense, great work and congrats on the site's traction. Using the build ID to namespace your assets is a good way to make sure old HTML points to the right JS chunks. The main trade off is how many old builds you want to keep around before cleaning them up since storage will creep up fast.

For the KV side I would lean on lazy revalidation like you described instead of trying to invalidate everything on each deploy. That scales better when you are talking millions of pages. The only real gotcha I have seen is forgetting to update cache keys when you change how you generate pages which can leave stale data hanging around.

Overall it looks maintainable as long as you have a cleanup policy and some automation around invalidation.

[fxmb]

Thanks for your feedback.

I wonder why Nextjs / Vercel does not offer this out of the box. ISR which comes closest to this is rather useless if you have to purge all cache on every build.

Do you happen to know an elegant way to solve the issue with RSC requests when users navigate between pages? It seems rather impossible to cache these between page changes.

[hyattc1]

ISR gets you part of the way there but it falls short when you have to invalidate everything on each build. With what you've said so far, I believe Vercel optimizes for the simpler case, smaller sites with fewer pages where global invalidation is not as painful, and leaves the more custom caching setups to teams that need it.

For RSC requests, there really is not a perfect built in solution yet. Since they are tightly coupled to the app router and the current build, caching them between navigations is tricky. The closest thing to an “elegant” approach I have seen is to treat them like API responses, put them behind KV or edge caching with a short TTL so you cut down on repeat fetches without risking users seeing stale data for long. Some people also cache them per build ID the same way you are handling static chunks, but then you still need a cleanup policy.

This isn't easy stuff, wishing you luck as you continue to develop this. Right now it is more about layering your own caching strategy on top. Not as nice as having it built into Next, but it is what seems to work in practice.

If that clears things up, feel free to mark it accepted so others can find it too.