Skip to Content
FrontendBundlesCacheCache Key Structure

Cache Key Structure

To ensure accurate scoping and avoid conflicts, all cache keys must follow a standardized structure based on the current context.

Key Components

Cache keys are constructed using the following elements:

  • Tenant: Identifier of the current tenant (e.g., demo-ecs)
  • Corporation: Corporation Id or "null" if not applicable
  • User: Optional user ID or "null" if not applicable
  • Namespace: Functional or domain-specific prefix for the cache entry (e.g., KVS, menu, config)
  • Additional Qualifiers (Optional): Any further qualifiers for clarity (e.g., entity ID, language)

## 🧩 Cache Key Format

<Tenant>_<CorporationId>_<UserId>_<Namespace>[...additional_qualifiers]

> Use `"null"` (as a string) when a component is not applicable.

🧪 Examples

ContextCache Key Example
Tenant-level menudemo-ecs_null_null_menu
Corporation-specific KVS entrydemo-ecs_3_null_KVS
User-specific configdemo-ecs_null_1001_config
Language-specific labels (optional)demo-ecs_null_null_labels_local

## 📝 Notes

- **Consistency is key**: Always use the same separator (`_`) and the `"null"` string for missing context values.
- **Avoid redundancy**: Only include components that influence the cache scoping.
- **Sanitize inputs**: Ensure all components used in keys are sanitized to avoid unexpected characters.
Last updated on
CacheCommon Issues