# CDN cache invalidation strategy documented; deployment process includes CDN purge or auto-purge configured

- **Pattern:** `ab-000984` (`deployment-readiness.rollback-recovery.cdn-purge`)
- **Severity:** low
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-000984
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-000984)

## Why it matters

Deploying new code without purging the CDN cache means users may receive stale assets — old JavaScript bundles, outdated HTML, broken references to renamed files — for hours or days after a deployment. ISO 25010 reliability.maturity requires that deployments deliver what was deployed. Without a documented invalidation strategy or automated purge step in the CI/CD pipeline, cache staleness is the default outcome, not the exception, and debugging it requires correlating CDN access logs rather than a simple cache clear.

## Severity rationale

Low because CDN staleness causes user-visible bugs and inconsistency after deployments, but doesn't expose data or cause security failures — the impact is reliability and UX degradation.

## Remediation

Add a CDN cache purge step to your deployment workflow. For Cloudflare in GitHub Actions:

```yaml
# .github/workflows/deploy.yml
- name: Deploy to production
  run: npm run deploy:prod

- name: Purge Cloudflare cache
  run: |
    curl -s -X POST \
      "https://api.cloudflare.com/client/v4/zones/${{ secrets.CF_ZONE_ID }}/purge_cache" \
      -H "Authorization: Bearer ${{ secrets.CF_API_TOKEN }}" \
      -H "Content-Type: application/json" \
      -d '{"purge_everything": true}'
```

For content-hashed assets (Next.js default), purge is less critical because filenames change with each build — but HTML and API responses still need invalidation. Document the purge command and the required secrets in `DEPLOYMENT.md`.

## Detection

- **ID:** `cdn-purge`
- **Severity:** `low`
- **What to look for:** Enumerate every relevant item. Look for CDN integration in deployment (Cloudflare, AWS CloudFront, Akamai, Bunny). Check CI/CD workflows for cache purge or invalidation steps. Check configuration files for auto-purge or cache busting setup (e.g., content hashing, deployment hooks).
- **Pass criteria:** At least 1 of the following conditions is met. A CDN cache invalidation strategy is documented. Deployments either include a cache purge step, or auto-purge is configured (e.g., via content hashing or deployment webhooks).
- **Fail criteria:** No CDN is in use, or CDN is configured but no invalidation strategy or purge mechanism exists.
- **Skip (N/A) when:** The project is not using a CDN, or all content is served dynamically.
- **Detail on fail:** `"CDN cache invalidation strategy not documented. Deployments do not include cache purge step."` or `"Cloudflare integrated but no purge_cache webhook configured in CI/CD."`
- **Remediation:** Set up CDN cache purge. For Cloudflare in GitHub Actions:

  ```yaml
  # .github/workflows/deploy.yml
  - name: Purge Cloudflare cache
    run: |
      curl -X POST "https://api.cloudflare.com/client/v4/zones/${{ secrets.CLOUDFLARE_ZONE_ID }}/purge_cache" \
        -H "Authorization: Bearer ${{ secrets.CLOUDFLARE_API_TOKEN }}" \
        -H "Content-Type: application/json" \
        --data '{"files":["https://your-domain.com/*"]}'
  ```

  Or enable auto-purge in Cloudflare dashboard:
  1. Go to Cloudflare → Caching → Cache Rules
  2. Set cache level to "Standard" or lower
  3. Enable "Purge cache on deploy" if available

---

## External references

- iso-25010 reliability.maturity

Taxons: operational-readiness

HTML version: https://auditbuffet.com/patterns/ab-000984