Custom caching strategy using Cloudflare Workers

Akash Agrawal
Feb 4 · 3 min read
Image courtesy Cloudflare Blog

Lenskart’s product catalog is extensively cached as this is one of our most frequently accessed services. It is at the core of a user’s discovery and product browsing behaviors, and product pricing is static enough that it can be cached blindly. Most of this is enabled via Cloudflare’s caching rules.

As a part of this year’s roadmap, we decided to simplify omnichannel returns and exchange for our users. The new UX enables our users to see the delta amount that they would have to pay while exchanging the product. Since this amount would differ as per the value of the product being exchanged, it would be ineffective to cache.

Hence, we had to find a way to serve products from the cache for a major chunk of our users, while also having a mechanism to have dynamically calculated pricing in case the user was looking for an exchange.


If Cloudflare deems a request cacheable, it first examines its cache in multiple network locations for content. If the resource is not present in the cache, Cloudflare requests the resource from the user’s origin webserver to fill its cache. The response is then sent to the client that initiated the request.

All in all, Cloudflare allows clients to cache responses based on headers but doesn’t allow the implementation of a caching strategy based on the presence or absence of the said header.

Cloudflare Workers

Cloudflare Workers lets developers deploy serverless JavaScript applications on Cloudflare’s global cloud network, where they are seamlessly scalable and closer to end-users. Based on the Service Workers API, Workers receive events for every HTTP(S) request made to an application.

Simple illustration of Cloudfare Worker

Workers provide a way to customize cache behavior using Cloudflare’s classic CDN as well as a private cache space.

A request’s cache key is what determines if two requests are “the same” for caching purposes. If a request has the same cache key as some previous request, then we can serve the same cached response for both.

Let’s see how we cached the request based on the custom value of a header using worker:

So what was the problem for us? Essentially, we didn’t want to cache the request if there is a certain header’s value in one of the Headers. We leveraged Cloudflare Workers for the same. We created a small piece of code to cache a request depending upon the header’s value.

addEventListener("fetch", event => {
let request = event.request
if ((request.headers.get("Header_Name") != "Header_value"))
const parsedUrl = new URL(request.url)event.respondWith(fetch(parsedUrl, { cf: { cacheEverything: true } }))

So basically what we’ve done here is to get the Cloudflare worker to check if the header_name does not contain header_value then cache the request.

This simple solution helped us to make one of our biggest projects live (:

Thanks to Nuzha Rukiya

Akash Agrawal

Written by

A computer geek, lover of programming and learner is how I would simply define myself. To challenge myself in field in Computers and Cyber Security.

Lenskart Engineering

Product and Engineering @ Lenskart

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade