Caching

The caching logic is defined within multiple layers.

LAYER 01Database● active

Caches requests by default unless explicitly disabled. First line of defense — closest to raw data.

LAYER 02CMS Response● active

CMS caches outgoing responses. Changes to vehicles, headers, footers & CMS entries automatically trigger revalidations.

⏱up to 5 min max rotation time — stale data possible in rare cases

LAYER 03Backend Request● active

Caches internal backend requests. Acts as a buffer between CMS responses and backend logic.

⏱up to 6 hours max rotation time — manual revalidation available

LAYER 04Backend Response● active

Caches outgoing backend responses. Supports partial Revalidation — page & banners are refreshed; header & footer are retained from cache.

⚡ Revalidation Queue — Priority-based queue system. Manual revalidation has very high priority. Average completion time: ~30 seconds. Making multiple changes in quick succession is safe — no risk of overloading.

LAYER 05Frontend (Static HTML)● active

Pages served as statically generated HTML. Updated last to guarantee freshest possible data. Browser-level caching may require a hard reload Ctrl+Shift+R to see some changes.

LAYER 06CDN Edge◌ disabled

Planned as an edge distribution layer for static HTML. Currently not active.

timing boundary

active layer

disabled layer

revalidation available

1. Database-layer

The database caches requests by default if not explicitly disabled.

2. CMS-response-layer

The CMS caches responses with a maximum duration of 5 minutes.

Note: Between layers 2 and 3, up to 5 minutes can pass before a full cache rotation is completed. In very rare cases, stale data may be returned during this window.

3. Backend-request-layer

The backend caches internal requests.

4. Backend-response-layer

The backend also caches its outgoing responses with a maximum duration of 6 hours.

Note: Between layers 3 and 4, up to 6 hours can pass before a full cache rotation is completed. A premature partial cache rotation can be triggered via Revalidation.

Revalidation

Revalidation reloads a page and its banners, but retains supporting structures like the header and footer. It is processed via a priority-based queue system. Manual revalidation has very high priority and completes in an average of 30 seconds, though it may occasionally take slightly longer.

Automatic cache invalidation

Since all systems communicate with each other, changes to vehicles, headers, footers, and other CMS entries are automatically translated into revalidations and cache rotations. For example, to rename a header entry, the header itself must be touched after the entry change, e.g. by briefly reordering items to trigger an automatic update.

The system avoids redundant work, so making multiple changes in quick succession is not a problem and poses no risk of overloading the system.

Only an actual header change will rotate the header-specific cache (the same applies to the footer). Subsequent page revalidations will then use the updated header object.

5. Frontend-layer

The frontend serves pages as statically generated HTML. This layer is updated last to ensure the freshest possible data is served.

Note: Since browsers also cache static HTML locally, it can be helpful to instruct the browser to reload without cache (hard refresh). Some changes may only become visible after doing so. This is a client-specific behavior that cannot be significantly controlled via standard cache headers.

6. CDN-layer (currently disabled)

A CDN cache is planned as an edge distribution layer for static HTML, but is currently not active.

Footer