Phase 4: Architecture & Scaling

HTTP caching with Cache-Control, ETags & conditional requests

Intermediate ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you're super excited to bake your favorite chocolate chip cookies, and you have a giant, amazing cookbook at the library that has all the best recipes. Every time you want to bake, you could go to the library, find the cookbook, flip to the cookie recipe, and write it down on a fresh card. But going to the library every single time takes a while, right? And the librarian (who represents a big computer server on the internet) gets super busy helping everyone else find their recipes too!

This is where your smart thinking comes in! Instead of going to the library every time, you get your own little recipe box at home. When you first get the cookie recipe from the library, the librarian might tell you, "Hey, this cookie recipe probably won't change for a whole week, so you can keep this card in your home box and use it for that long!" For seven days, you just open your box, grab the card, and start baking – super fast! You've just "cached" the recipe, meaning you've stored a copy closer to you to save time and trips.

But what happens after a week? Or what if it's a "Daily Special" recipe that changes all the time? Well, you don't always need to copy the whole recipe again. When your week is up, or if it's a recipe that needs to be checked often, you can go back to the library. But instead of copying everything, you bring your old recipe card and simply ask the librarian, "Is this cookie recipe still the latest one, or has it changed?" The librarian is clever! They might have a little secret version number written on their copy, like "v3.1." They quickly compare your "v3.0" with their "v3.1" and can tell you in a flash, "Nope, it's new! Here's the updated part," or "Yep, still the same, you're good to go!" This way, you don't waste time copying it all again, and the librarian doesn't have to read out the whole recipe.

So, imagine you are the super-smart head librarian who organizes the big cookbook for everyone. You get to decide which recipes people can put in their home boxes, for how long they can keep them, and how they should check for updates. You might tell them, "Keep this cookie recipe for a week," or "This daily special changes constantly, so always ask me first!" When you build things on the internet, this means you can make your creations load super quickly for people, because you're helping their computers keep copies of information, saving everyone time and making the internet a faster, happier place!

HTTP caching is a fundamental strategy for improving performance and reducing server load by storing copies of resources closer to the client. As a backend developer, you control this process primarily through HTTP response headers. The Cache-Control header is your primary directive, telling clients (browsers, proxies) how to cache your responses. Directives like max-age=3600 instruct clients to cache a resource for 3600 seconds, avoiding re-fetching it during that period. Other important directives include no-cache (revalidate before using), no-store (never cache), public (cacheable by any cache), and private (cacheable only by private caches, like a browser's own cache). Properly setting Cache-Control can significantly reduce the number of requests hitting your backend for static or infrequently changing content.

While Cache-Control: max-age handles initial freshness, resources eventually expire or might become stale. This is where conditional requests come into play, allowing clients to ask, "Is my cached version still valid?" without downloading the entire resource again. The server facilitates this using ETags (Entity Tags) or Last-Modified headers. When your server sends a response, it can include an ETag (a unique identifier for that specific version of the resource, often a hash) or Last-Modified (the timestamp of the resource's last modification). The client stores this with its cached copy.

On subsequent requests for the same resource, the client sends these identifiers back to your server using If-None-Match (for ETag) or If-Modified-Since (for Last-Modified). Your backend then checks if the resource has changed. If it hasn't, you respond with a 304 Not Modified status code, indicating that the client's cached version is still good. This saves significant bandwidth and processing power, as you avoid sending the full response body. By mastering these headers, backend developers can offload substantial work from their servers and provide a snappier experience to users.

Key Takeaways

  • Cache-Control dictates if and how clients can cache responses (e.g., max-age for expiration).
  • ETags and Last-Modified provide unique identifiers for resource versions and modification times.
  • Clients use If-None-Match and If-Modified-Since for conditional requests to revalidate cached content.
  • A 304 Not Modified response tells clients to use their existing cached copy, saving bandwidth and server load.
  • Backend developers are responsible for setting these HTTP headers to optimize performance and reduce infrastructure costs.

Code Example

javascript
Preview

How this code works

This code sets up a simple web server using express to demonstrate how to implement HTTP caching for an API endpoint returning product data. Its main purpose is to show how a server can instruct clients (like browsers) to cache data, and then efficiently verify if their cached copy is still fresh, preventing unnecessary data transfers. It accomplishes this using standard HTTP headers: Cache-Control for general caching rules and ETag for content validation.

When a client makes a GET request to /api/product/:id, the server first simulates fetching product data and generates a unique etag – a content fingerprint – using crypto.createHash('md5'). It then sets Cache-Control: public, max-age=60, telling the client to cache the response for 60 seconds, and includes the ETag header. A crucial step follows: the server checks req.headers['if-none-match']. If the client included this header with an etag that matches the server's current one, it means the client's cached data is still valid. The server then responds with res.status(304).send(), signaling "Not Modified," and uses return to immediately stop processing, avoiding sending the full product data and saving bandwidth. Otherwise, it sends the complete res.json(product).

Related Articles

Hand-picked reads to go deeper on caching strategies.

Back to Backend Developer Roadmap