l1l2-cache-patterns

Implement two-tier caching by using an in-process L1 freecache with 60s TTL per replica and a shared L2 Dragonfly cache with 300s TTL, ensuring tenant isolation through tenant-prefixed keys for GET-by-ID lookups.

Maintain cache coherence by emitting NATS events from the DAL to entity services, triggering synchronized eviction and invalidation flows across both L1 and L2 cache layers whenever underlying data changes.

Yes, tenant isolation is supported by applying tenant-prefixed keys across both the in-process freecache L1 layer and the shared Dragonfly L2 cache, preventing cross-tenant data access during GET-by-ID lookups.

Minimize database load by checking the per-replica L1 freecache first, then the shared L2 Dragonfly cache, so that PostgreSQL is only queried by the DAL when the requested data is absent from both cache tiers.

Yes, NATS events are used specifically to drive cache invalidation and eviction flows to keep L1 and L2 coherent, while explicitly avoiding NATS KV Store for caching to ensure data consistency through the DAL.

Avoid relying solely on a shared L2 cache when ultra-low latency is critical, as the per-replica L1 freecache handles hot data access faster; L2 Dragonfly serves as a fallback to reduce PostgreSQL load before hitting the database.