Three-Layer Caching for a Multi-Tenant CRM

Consider a CRM record page that loads a record, its layout, and the current user's permissions. This is an illustrative workload related to my CRM work. Those pieces have different lifetimes and different access rules. Treating the complete response as one reusable object makes it difficult to invalidate safely, especially when the same record looks different to different users.

Before changing the architecture, trace a slow request through authorization, database queries, serialization, and network delivery. A missing index or repeated query might explain most of the wait. Caching that work can hide the cause while adding another system to maintain. Write down which part is expensive, which part repeats, and how stale each answer is allowed to be.

Request-local memory is useful when several handlers need the same data during one request. Its lifetime ends with that request. A process-wide cache is different: it survives requests and needs a size limit, expiration, and a plan for invalidation. It also disappears when the process restarts and is not automatically shared with other application instances.

Redis can hold reusable data across instances. HTTP caching applies to responses and needs its own policy. These layers do not have to form one mandatory pipeline. An authenticated record response might bypass HTTP storage while its public static assets are cached aggressively. A small request-local lookup may never need Redis. Choose layers independently for the data they can safely reuse.

A record ID alone is not a sufficient key in a multi-tenant application. Include tenant identity, and distinguish representations when the serialized shape changes. If the result depends on filters, sorting, locale, or field selection, those inputs also affect identity. A key for an unfiltered collection cannot safely stand in for every search result derived from it.

For the worked example, cache a tenant-scoped record representation, authorize each request, then apply any user-specific field visibility before producing the response. Do not treat possession of a cache key as permission to read it. If permission-filtered responses are cached instead, changes in permission state become part of the invalidation problem as well.

Imagine a user changing a company's name. The record page may be cached, but so might search results and lists that include that name. Deleting one record key does not refresh all of those views. Document the dependency set before adding cached collections. Sometimes keeping the record cache and leaving the search query uncached is the simpler correct choice.

Commit the database write before removing the stale entry. Even that sequence has a race: an earlier reader can finish afterward and refill an old value. Expiration limits how long an entry can survive, but does not guarantee immediate consistency. Stronger requirements may call for version-aware fills or bypassing the cache on sensitive reads. An invalidation failure also needs an observable recovery path.

When a popular entry expires, several requests may ask the database for it at once. Sharing one in-flight read within a process reduces duplicate work there; it does not coordinate every server. Staggered expiration can reduce synchronized misses. The appropriate approach depends on whether recomputing an item is cheap or can overwhelm the underlying service.

A Redis outage must have a bounded effect. Set short connection and command timeouts and decide whether the endpoint can fall back to the database. Unrestricted fallback can overwhelm a database sized for normal cache misses, so concurrency limits and load shedding may be necessary. Never turn an infrastructure timeout into a successful empty record that clients might interpret as real data.

Public caching belongs on content that may be shared between users. Personalized CRM responses should not enter a shared cache. A private directive permits browser storage while excluding shared caches; no-store requests that the response not be stored. No-cache has a different meaning: storage is allowed, but reuse requires validation. Check the deployed CDN configuration as well as application headers.

Test with two separate users and two tenants. Inspect actual response headers and repeat the request after changing access rights. A fast response is not a success if it contains another user's fields. Browser navigation, reloads, and sign-out are useful parts of this check because cached responses can outlive the screen that first requested them.

Compare the same workload before and after the change: cold reads, warm reads, concurrent writes, and cache outages. Track database request volume, tail latency, errors, memory use, and observed staleness. A high hit rate alone can hide incorrect keys or stale data. Use bounded-cardinality labels for metrics; tenant or record identifiers rarely belong in every time-series label.

For a small service, a well-indexed query plus a request-local lookup may be enough. Add Redis when repeated cross-request work justifies it, then add HTTP caching only where responses permit reuse. The goal is a read path whose behavior you can explain during an update or an outage, with a measured benefit that pays for the additional complexity.