Caching is a contract with your application
A cache is useful when the application can clearly define how long a response remains valid. Apex separates cacheability from persistence: a response can be cached at the edge even when the source of truth stays in your database.
Start with three questions
- What makes two responses equivalent enough to share? Define a cache key from stable request inputs.
- How long can a response be stale? Choose TTLs from business tolerance rather than a generic number.
- What event makes the cached representation invalid? Prefer targeted revalidation after writes.
Use tags for product-shaped invalidation
For content-heavy products, a simple URL purge can be too broad. Tag-based invalidation lets a publish event invalidate a document, its category pages, and derived recommendation fragments without clearing the entire cache.
curl -X POST https://api.apex.dev/v2/cache/purge \
-H 'Authorization: Bearer $APEX_TOKEN' \
-H 'Content-Type: application/json' \
-d '{"tags":["product:sku_1842","collection:summer"]}'Protect correctness before optimizing hit rate
A 99% hit rate is not useful if a user sees outdated inventory or permissions. Cache only representations whose validity you can explain, and include the invalidation event in application telemetry so operators can verify the contract during an incident.
Go from cache policy to implementation
The cache tutorial shows how to separate static delivery, dynamic responses, and targeted invalidation in one project.