Why CDN edge rules returned stale logos with invalid cache-control and the surrogate key setup that allowed immediate purges

Modern web applications rely heavily on Content Delivery Networks (CDNs) to ensure rapid asset delivery to users across the globe. However, even with the best infrastructure, faulty configurations can lead to inexplicably sluggish updates or, worse, incorrect visuals being shown to users. Recently, a surprising issue emerged with logo assets being served stale from edge locations, defying expectations around cache-control behavior. Here’s what happened and how it was resolved through changes to edge rules and a smarter use of surrogate keys.

TL;DR

CDN edge rules inadvertently instructed cache nodes to retain old versions of logo assets due to incorrect cache-control directives. This led to outdated or mismatched logos being displayed even after updates were made. By revisiting how cache-control headers were set and implementing surrogate keys for asset-specific purging, immediate logo refreshes became possible without edge cache persistence issues. The fix dramatically improved consistency and reliability of brand assets across all user locations.

What Went Wrong: The Root of the Stale Logo Issue

At the heart of the problem was a misconfiguration in CDN edge rules, particularly how cache-control headers were interpreted and applied across different layers of edge caching. Assets—most notably logos used throughout the application—were being cached with the wrong assumptions. Here’s how things broke down:

• Invalid Cache Headers: Logos were being served with Cache-Control: public, max-age=31536000 even during active development and frequent updates. This header effectively told the CDN and browser to cache the assets for a full year.
• No Cache Invalidation: Without any cache-busting query parameters or file name versioning in place, changes to logo files did not trigger updates at the CDN level.
• Sticky Edge Locations: Some edge servers failed to pick up updated assets until forcibly purged, leading different users to see different versions of the same logo depending on where they were located.

These issues compounded over time, especially because branding updates weren’t regular enough to warrant constant attention—until a major rebrand showed that the CDN simply wasn’t catching up.

How CDN Edge Logic Misinterpreted Cache-Control

CDNs interpret cache headers to determine how long to serve the cached versions from edge nodes. The intention had been to set long cache durations only for immutable files. Instead, an edge rule applied a sweeping policy that imposed long-term caching on any asset with a .svg or .png extension, regardless of versioning or update policies.

This blanket rule backfired. Legacy systems worked under different assumptions: previously, logos were updated only a few times a year, and teams used manual invalidation. However, the new design system allowed marketing teams to change logos and visuals directly, meaning these files could update weekly or even daily. Without smarter cache-control logic, the CDN couldn’t differentiate between a new logo version and one that should stay cached.

Detecting the Issue

The first signs of trouble came when some internal teams reported seeing old branding after updates had rolled out. Developers noticed that despite updating the logo.svg file on the origin server, some CDN nodes continued to serve the older version. Browser caches were being ruled out, and all signs pointed to the edge nodes not respecting update timestamps.

A thorough audit of HTTP headers showed discrepancies between the origin response and the CDN’s cached asset:

• Origin Response:
  Cache-Control: no-cache, must-revalidate
• CDN Response:
  Cache-Control: public, max-age=31536000

This mismatch wasn’t accidental; it was the result of an overzealous edge rule that overrode the origin headers for file extensions commonly deemed “safe.” In this case, the assumption that logos rarely change was explicitly codified into risky permanence.

Enter Surrogate Keys: The Game-Changer

To address the issue, a new system of surrogate keys was implemented. Surrogate keys are custom headers that let you tag specific assets or asset groups during delivery so they can be manipulated or invalidated as a group. For CDN providers that support advanced tagging (like Fastly or Cloudflare), this approach offers tremendous flexibility.

Here’s how it helped resolve the problem quickly and elegantly:

1. Each visual asset was tagged with a unique surrogate key. For example, X-Surrogate-Key: logo-main.
2. Purge commands were modified to target keys rather than entire URLs. This allowed for micro-invalidation, affecting only the precise logo asset updated.
3. Edge rules were refined to stop blindly overriding cache headers and instead honor cache-control values provided by the origin.

With surrogate key-based purging in place, logos could be updated and force-propagated across the entire CDN footprint just seconds after deployment—without clearing all user sessions or waiting for cache expiration.

New Caching Policy with Dynamic Context

Post-fix, a smarter and more context-aware cache policy was adopted. Assets were split into two categories based on modification frequency:

• Static Assets: Files like fonts, legacy icon sets, and documentation images were allowed a long max-age with versioning built into their filenames—for example, icon-v2.4.1.svg.
• Dynamic Visuals: Assets like branding logos and marketing visuals were retained under a TTL of 5 minutes. These also carried surrogate keys to allow on-demand invalidation.

An automated purge system was also enabled via CI/CD pipelines. When a logo file was changed in Git, the resulting deployment script triggered a CDN purge using the surrogate key associated with that logo. This added a layer of autonomy and removed any reliance on manual purging tools.

Bonus Benefit: Developer and Designer Alignment

Another welcome outcome of this change was tighter coordination between engineering and design teams. Since designers now had the ability to preview changes via staging environments and push visual updates into production, it became crucial to visualize how CDNs cached and delivered those changes. Now, with real-time purging capabilities, feedback loops shortened, and branding consistency was maintained globally in minutes.

Lessons Learned and Key Takeaways

This issue served as a powerful reminder that CDN configurations, while out of sight, have enormous impact on how users experience your product. Here are a few concluding thoughts:

• Don’t blindly cache image assets based solely on file types. Context matters—logos are not icons, even if they share the same file extension.
• Use versioning or surrogate keys for assets likely to change. Either one will help avoid stale-cache hell.
• Always audit your CDN edge rules when unexpected behavior crops up. Small misconfigurations can have global ripple effects.
• Set up observability tools that monitor cache behavior across your CDN footprint. Debugging edge caches is not fun—unless you’re well-prepared.

Final Thoughts

The problem of stale logos was frustrating, but it ultimately led to a far more robust asset delivery pipeline. Ensuring that cache-control and invalidation mechanisms respect the evolving nature of your assets is less about technical wizardry and more about empathizing with user-facing reliability. With surrogate keys and better cache strategies in place, the CDN became a truly transparent and powerful ally rather than an unpredictable black box.