Org Cache

What Org Cache Is In Practice

An org cache is a shared cache boundary for a single organisation or tenant. It is designed to hold temporary data that multiple authorised users or processes inside that boundary can reuse, which reduces repeated lookups, keeps tenant data isolated from other organisations, and can improve performance for common values.

That tenant-scoped design is the key distinction. A cache is not just a faster storage layer; in this pattern it becomes a shared operational resource whose scope, eviction behaviour, and data separation rules must match the organisation boundary.

Where Org Cache Fits In Application Design

Org cache is usually used for values that are expensive to recompute or fetch repeatedly, such as tenant configuration, reference data, permission lookups, feature flags, or other session-independent state. Because the cache is shared within the tenant, one user or worker can populate it and another can benefit from the same entry.

That makes the pattern useful in multi-tenant systems where the organisation, not the individual session, is the right unit of reuse. It also means the application must be explicit about cache keys, because tenant identifier collisions or weak key design can turn a helpful optimisation into a data isolation defect.

Benefits And Trade-Offs Of Shared Tenant Caching

The main benefit is efficiency: fewer database reads, less backend contention, and lower latency for values that many requests need. A shared org cache can also reduce duplication when the same organisation has many active users or services touching the same data.

The trade-off is stronger coupling. When cached data changes, every consumer in that organisation may depend on freshness, so stale entries can spread incorrect authorisation decisions, outdated configuration, or inconsistent user experience. Cache invalidation, time-to-live settings, and tenant-aware eviction therefore become part of the design, not an afterthought.

Tenant Isolation And Consistency Considerations

Because the cache is scoped to an organisation, isolation is the defining safety property. The cache key structure, namespace separation, and access controls must prevent one tenant from reading or influencing another tenant’s cached data, even indirectly through shared infrastructure.

Consistency is the other concern. If the org cache stores values that affect business logic, then stale or partial updates can create mismatches between what the cache says and what the source of truth says. In practice, the safest org cache designs treat it as a performance layer only, with authoritative state still enforced by the underlying system of record.

Risk and Threat Considerations

Shared tenant caches can leak data or logic across organisational boundaries if cache keys are incomplete, namespace separation is weak, or invalidation logic fails. The risk is not only confidentiality, but also incorrect behaviour when one tenant receives another tenant’s configuration, permissions, or session-adjacent values.

Failure mechanism: A cache entry is reused beyond its intended tenant scope, or remains stale after the source data changes, so the application makes decisions on the wrong data.

Impact: Cross-tenant exposure, broken access decisions, inconsistent application behaviour, and difficult-to-trace faults that may persist until the cache is flushed or corrected at the source.

Practitioner Guidance

What to watch for: Treat the cache key as part of the security boundary. If the cached value is tenant-sensitive, include the organisation identifier in the keying model and make cache invalidation explicit when source data changes.

Governance implication: Decide which data is safe to share across requests inside a tenant and which must never be cached at all. The stricter the data’s effect on access, billing, or configuration, the more conservative the caching policy should be.

Practitioner takeaway: An org cache is only safe when the tenant boundary is enforced in both data selection and data reuse, not just in the application’s general access model.

Related resources from NHI Mgmt Group

• Who should own org-scoped API keys versus user-scoped API keys?
• What is the difference between org-wide RBAC and resource-scoped authorization?
• Who is accountable when a connected Salesforce org is revoked or misused?
• What is the difference between request-scoped caching and a shared application cache?