Cache Invalidation

Content in the read-through cache can be invalidated by sending events via StreamHub. Invalidation events hook into the same mechanism used by TCS Sidecar, enabling longer cache-expiry TTL values.

Invalidation delay is the sum of StreamHub delay, backing-store latency and sidecar invalidation delay - see dashboards section below for how to observe these.

Sending Invalidation Events

Events published to StreamHub should use the schema and type/AVI format below:

Invalidation AVI

1
2
# Following avi:<source>:<action>:<contentType>
# e.g. avi:cs-extensions:invalidation:app-definition
avi:<micros_service>:invalidation:<record_type>

Schema

See the Shipyard Artifact in the Shipyard UI.

1
2
{
  "$id": "http://example.com/example.json",
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "TCS Read-through Invalidation Event",
  "description": "Cache invalidation event, emitted by services using Tenant Context Service's read-through cache.",
  "type": "object",
  "definitions": {},
  "dataTypes" : ["UGC/Configuration"],
  "properties": {
    "key": {
      "type": "string",
      "description": "The unique identifier for the data being invalidated. Used to load from cache backing store."
    },
    "recordType": {
      "type": "string",
      "description": "Type describing the data being invalidated. Used to route to correct cache-loader"
    },
    "version": {
      "type": "integer",
      "description": "Events with versions less than the currently cached data will be ignored."
    },
    "timestamp": {
      "type": "integer",
      "description": "Timestamp when the event is pushed to StreamHub."
    }
  },
  "required": [
    "key",
    "recordType",
    "version",
    "timestamp"
  ],
  "additionalProperties": false
}

Cache Loader Behaviour

An invalidation event will trigger a ‘refresh’ (reload the key from backing-store) if:

• a TCS webserver node has cached the key, and
• either
  • the cached version is less than the specified ‘new version’ in the invalidation event, or
  • regardless of cached version, if the invalidation event contains version: -1 (not found - deleted), or -2 (force refresh)

Nodes without the cached key will ignore the event.

As TCS is deployed to seven AWS regions, the backing store could receive up to ~30 requests for each event (7 regions * 4 nodes), if all nodes are caching the given key.

Each node has a configurable concurrent request limit - default of 15 concurrent requests per-record-type. Mar 21, 2023 This limit applies to cache access, but not background reload (e.g. invalidation). Where a cache miss would exceed the request limit, it is rejected and HTTP status code 429 is returned to the client. TCS will retry invalidation events if loading fails for any reason.