Skip to content

architecture: caching

One of the most common strategies to improve performances of web applications is the use of caching. siibra-api can be configured to use a gzipped b64 redis store to cache responses, used in fastapi middleware

flowchart TD

    Internet
    RespCache[Cache database]
    OpenshiftServer[Server Pod]

    Internet --> |queries| OpenshiftServer
    OpenshiftServer --> |caches| RespCache
    RespCache --> |provides cache| OpenshiftServer

    OpenshiftServer --> |responds| Internet

Gzipped b64 redis store

The redis store is designed to store key (gzipped base64 encoded) value. Whilst incur performance cost on read and on write, the advantage of such approach was the non-trivial improvement of resource efficiency.

Caching criteria

The caching criteria can be found in the fastapi middleware.

In short, a response will be cached if and only if:

  • HTTP verb is GET and
  • auth header not provided and
  • url.path does not contain banned keywords (metrics, openapi.json, atlas_download) and
  • url.query does not contain banned keywords (bbox=, find=) and
  • response is of type application/json

Cache invalidation

As the key used in fastapi middleware contains siibra api version, on increment of siibra-api version, the cache will be invalidated.