Caching

Caching is what makes a serverless image stack economically viable: the first request for a unique (asset + preset + options) pays for S3 read, CPU, and egress; the next thousand requests for the same variant should hit CloudFront (and often the browser) without re-running Lambda. Bad keys or TTL choices show up as cost spikes and stale images.

Cache layers (browser, CDN, origin)

Layer	Role
Browser	Keeps a copy per URL (and cache policy). Fast for repeat views on the same device; use ETag / If-None-Match if you use revalidation.
CloudFront (CDN)	Global cache; this is the main amortization layer for Rendorix. Tune per-path behavior and query-string forwarding so signed parameters participate in the key as needed.
Origin (Lambda result)	No long-lived “disk cache” on Lambda itself—warm invocations help latency only. Durability of variants is the CDN cache, not the worker.

S3 is the source of truth for originals; it is not a “cache of variants” in the same sense—variants are derived and then CDN-cached.

Cache keys

A cache key should uniquely identify the response bytes for a request. In practice that means including every input that can change the output, for example:

• Asset identifier (path, key, id).
• Preset and any allowed override parameters.
• Format negotiation (e.g. Accept: image/avif vs image/webp) if your origin returns different bytes per Accept—then Vary or explicit URL strategy must align.

Signed query parameters: the signature and exp often must be part of the key (or the URL is unique per signature) so different links do not collide. If the CDN strips query strings from keys by misconfiguration, you get wrong-image bugs or constant misses.

Stale content and revalidation

• Served images can stay “fresh” in the browser and CDN for the max-age you set, even if you re-upload a new original in S3. That is a feature (performance) and a footgun (updates).
• Mitigations: shorter max-age for hot assets, content-addressed or versioned paths for originals, or CloudFront invalidation when you need a global purge (use sparingly—operational and cost).

Purging and invalidation

• Per-object invalidation in CloudFront is an ops tool, not a per-user “undo” for every edit.
• Versioned asset URLs (/v2/photo.jpg or photo-a1b2c3.jpg) make caches self-align when you deploy new bytes.

Document your team’s default: “we bump the path when the asset changes” vs “we accept CDN delay until TTL.”

Operational runbooks (placeholders)

• “Wrong image in EU but not US” — Regional cache / replication; check CloudFront behavior and key normalization (trailing slash, case).
• “Bill spike after launch” — Low hit rate: unique URLs (per-request query noise), or thundering herd on expired cache.
• “403 after cache layer” — Unlikely to be “cached 403**” if you don’t cache errors; more often signing bugs or expired links.

Tie runbooks to observability: 4xx/5xx at edge, Lambda duration, S3 GETs, and cache hit ratio (where available).

Related reading

• TTL — how HTTP TTL interacts with signed link lifetime
• Architecture — where caching sits in the request path
• Tradeoffs — cost vs freshness