HTTP caching looks simple; getting the cache key and exception handling right in production is hard.
HTTP caching is straightforward in theory: when Cache-Control, ETag and TTL values are correct, clients and intermediaries reuse the same response. In production, applications routinely send these headers missing, wrong or overly restrictive. The result is that cacheable content keeps hitting the backend unnecessarily.
Even for static assets, small URL differences erode cache efficiency. The same product image or catalogue page can behave like a different object because of tracking parameters. Host, query string, client headers or a misconfigured Cache-Control header needlessly lower the cache hit ratio.
For dynamic content the problem is larger. The same path may return different responses for mobile and desktop; prices can vary by country; the same endpoint can produce different data per tenant. If the cache key does not carry that context, the wrong content is returned. Add too many headers to the cache key and the cache barely works at all.
External cache or CDN solutions are useful at the internet edge, but they are not always suitable for on-premises, private API or sovereign cloud traffic. Doing cache at the ADC layer typically requires configuration files, a custom rule language or a separate product.
TR7 Response Caching brings cache profiles, conditional rules, dynamic cache keys and standard override options together under a single vService management model.
Our approach
TR7 manages cache behaviour through four layers: profiles, conditions, dynamic keys and controlled overrides.
Named cache profiles provide per-service quotas
A cache profile gathers name, size, TTL, ETag and debug header settings in one place. The same profile can be shared across multiple vServices while each service is governed by its own cache limits.
Conditional cache rules make per-endpoint decisions
Each cache rule binds to path, method, header, cookie or other variables through the FX condition engine. A public catalogue on the same backend can be cached while the user's cart is excluded — without changing any application code.
Dynamic cache keys prevent wrong-content responses
Country, device type, tenant ID, user segment or a custom header can be added to the cache key. The same URL splits into separate cache slots per context, preserving cache speed while strengthening content correctness.
Standard override options improve cache efficiency
Host, query string, request header and response header checks can each be deliberately bypassed. Misconfigured backends or tracking parameters no longer suppress hit rates. Operators decide explicitly which standard to override and when.
Capabilities
Response Caching makes every behaviour — from cache profile to dynamic key — configurable at the vService level.
Named cache profiles centralise size and TTL configuration
Each profile is defined with a name, maximum size and timeout. The size limit keeps per-service cache usage under control. Timeout is configurable in seconds, minutes or hours. Applying the same profile to multiple vServices reduces operational repetition.
Cache hit and miss are visible via a response header
TR7 can add a debug header to responses, letting a developer or operator see in the browser Network panel whether a response came from cache or from the backend. No additional log tool is needed for quick verification — it speeds up commissioning and tuning.
Conditional cache rule list gives per-endpoint control
Multiple rules can be defined within a single cache profile. Each rule is triggered by path, method, header, cookie or FX conditions. `/assets/*` can be cached for a long time while `/api/cart` is excluded. Different cache behaviours within one vService are managed from a single panel.
ETag support eliminates unnecessary data transfer
ETag can be enabled per rule. When a client requests the same object again and the content has not changed, it receives a validation response instead of the full body. This reduces bandwidth consumption and is especially effective for static assets and infrequently changing API responses.
Dynamic cache keys create separate slots per context
When dynamic caching is on, custom variables can be added to the cache key. Country, device type, tenant ID, A/B test group or a value extracted from a JWT can all become part of the key. The same URL separates cleanly across contexts. This makes caching practical for modern API and SaaS scenarios.
Host ignore consolidates multi-domain content into one cache slot
When the same backend serves identical content under multiple domains, Host can be removed from the cache key. Domains like `a.example` and `b.example` can then share the same cached object, reducing cache duplication. This option should only be used when the content is genuinely shared.
Query ignore stops tracking parameters from breaking the cache
`utm_source`, campaign codes and analytics parameters can make the same content appear as different objects. With query ignore active, these parameters are excluded from the cache key. The same page under multiple tracking-parameter variants no longer hits the backend repeatedly. Hit rates for public content improve noticeably.
Request check ignore limits client-side cache busting
Some clients or bots add headers that attempt to bypass caching on every request. Request check ignore lets that behaviour be deliberately disregarded. Static content and public API responses are shielded from unnecessary backend load. This setting should be applied carefully on security-sensitive endpoints.
Response check ignore can override misconfigured backend headers
A backend may mistakenly send `no-store` or overly restrictive cache headers. Response check ignore lets operators deliberately bypass those headers. Cache benefits are gained without changing application code. This option should only be used for deterministic and safe responses.
All-methods caching supports GraphQL POST scenarios
Standard HTTP cache behaviour focuses on GET and HEAD responses. TR7 allows operators to include POST responses in cache scope as well. This is especially useful when GraphQL queries arrive over POST. Body hash or relevant FX variables can be added to the cache key to ensure safe separation.
Memory-based cache is managed through soft reload
The cache is held in runtime memory. Configuration changes are applied via a soft-reload model; no runtime invalidation endpoint is claimed. Updating a cache profile or rule refreshes the relevant cache behaviour. When the device restarts, the cache begins warming again from empty.
Least-recently-used objects are evicted automatically
When the cache size limit is reached, the least-used or stale objects are evicted. Operators do not need to manage individual objects manually. The size limit prevents one vService's cache from affecting other services. The profile size can be increased for large asset catalogues.
Operational depth
Response Caching should be planned alongside cache TTL, object size, key design, the invalidation model and security boundaries.
Cache size
Maximum size for a cache profile is defined in MB; up to 2048 MB per profile is supported. Larger profiles suit big asset catalogues; a lower limit is sufficient for small API response caches.
Minimum timeout
A very short TTL causes cache thrashing and diminishes caching benefit. TR7 enforces a minimum of 10 seconds to prevent needless fill-and-empty cycles. TTL should be tuned to the update frequency of each endpoint.
Cache key security
A poorly designed cache key can return user- or tenant-specific content in the wrong context. When differentiation by tenant, country, device type or user segment is needed, those values must be included in the dynamic cache keys. Sensitive endpoints should be excluded from caching by default.
Restart behaviour
The cache is memory-based; it starts empty when the device or service restarts. This eliminates the complexity of persistent disk cache. The cache warms up again with the initial traffic wave.
Rule-based refresh
No runtime invalidation endpoint is claimed. Cache behaviour is managed by editing profiles or rules and triggering a soft reload. To change the behaviour of a specific endpoint, update the relevant cache rule.
Audit and operations
Cache profile, timeout, ignore option and dynamic key changes should be captured in the audit log. Who changed which endpoint's cache behaviour is visible. This is especially important for compliance and incident analysis.
When to use it
Country-based caching for e-commerce product catalogues
Product pages and catalogue APIs are cached for a defined period. Country is added to the cache key so markets with different prices or stock levels receive the correct content.
Short-lived caching for public API responses
News, announcement or public content endpoints can be cached for a few minutes. Query ignore prevents tracking parameters from lowering the hit ratio.
Per-tenant isolation for multi-tenant SaaS content
Tenant ID or a custom header is added to the cache key. The same path routes safely to separate cache slots for different tenants.
Controlled caching of GraphQL POST query responses
Even when GraphQL queries arrive via POST, deterministic queries can be cached. Body hash or relevant FX variables are added to the cache key to minimise the risk of returning a wrong response.
Offloading static asset traffic from the backend
CSS, JS, images and font files are cached with a long TTL. With ETag active, clients skip the full body download when unchanged content is requested.
Separate render cache for mobile and desktop
User-Agent family or device class is added to the cache key. The same URL is held in separate cache slots for mobile and desktop.
Frequently asked questions
How do standard headers such as Cache-Control and ETag work with TR7?
What is the difference between dynamic cache keys and the Vary header?
Can some endpoints be cached while others are excluded within the same vService?
How does cache invalidation work — is there a runtime API?
Can GraphQL POST responses be cached?
What are the recommended values for cache size and timeout?
Cut backend load with response caching
Cache profiles, conditional rules, dynamic keys and RFC-compliant override options for response caching. Let us walk through a live setup on your own services.