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.
TR7 manages cache behaviour through four layers: profiles, conditions, dynamic keys and controlled overrides.
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.
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.
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.
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.
Response Caching makes every behaviour — from cache profile to dynamic key — configurable at the vService level.
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.
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.
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 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.
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.
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.
`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.
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.
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.
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.
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.
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.
Response Caching should be planned alongside cache TTL, object size, key design, the invalidation model and security boundaries.
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.
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.
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.
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.
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.
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.
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.
News, announcement or public content endpoints can be cached for a few minutes. Query ignore prevents tracking parameters from lowering the hit ratio.
Tenant ID or a custom header is added to the cache key. The same path routes safely to separate cache slots for different tenants.
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.
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.
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.
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.