Hubbry Logo
Cache invalidationCache invalidationMain
Open search
Cache invalidation
Community hub
Cache invalidation
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Cache invalidation
Cache invalidation
Cache invalidation
View on Wikipedia
from Wikipedia

Cache invalidation is a process in a computer system whereby entries in a cache are replaced or removed.

It can be done explicitly, as part of a cache coherence protocol. In such a case, a processor changes a memory location and then invalidates the cached values of that memory location across the rest of the computer system.

Explicit invalidation

[edit]

Cache invalidation can be used to push new content to a client. This method functions as an alternative to other methods of displaying new content to connected clients. Invalidation is carried out by changing the application data, which in turn marks the information received by the client as out-of-date. After the cache is invalidated, if the client requests the cache, they are delivered a new version.[1]

Methods

[edit]

There are three specific methods to invalidate a cache, but not all caching proxies support these methods.

Purge

[edit]

Removes content from caching proxy immediately. When the client requests the data again, it is fetched from the application and stored in the caching proxy. This method removes all variants of the cached content.[1]

Refresh

[edit]

Fetches requested content from the application, even if cached content is available. The content previously stored in the cache is replaced with a new version from the application. This method affects only one variant of the cached content.[1]

Ban

[edit]

A reference to the cached content is added to a blacklist (or ban list). Client requests are then checked against this blacklist, and if a request matches, new content is fetched from the application, returned to the client, and added to the cache.[1]

This method, unlike purge, does not immediately remove cached content from the caching proxy. Instead, the cached content is updated after a client requests that specific information.

Alternatives

[edit]

There are a few alternatives to cache invalidation that still deliver updated content to the client. One alternative is to expire the cached content quickly by reducing the time-to-live (TTL) to a very low value. Another alternative is to validate the cached content at each request. A third option is to not cache volatile content requested by the client. These alternatives can cause issues, as they create high load on the application due to more frequent requests for information.[1]

Disadvantages

[edit]

Using invalidation to transfer new content can be difficult when invalidating multiple objects. Invalidating multiple representations adds a level of complexity to the application. Cache invalidation must be carried out through a caching proxy; these requests can impact performance of the caching proxy, causing information to be transferred at a slower rate to clients.[1]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Cache invalidation

View on Grokipedia
from Grokipedia
Cache invalidation is the process of removing or updating outdated entries in a cache to ensure that the stored remains consistent and accurate with respect to the original source, such as a database or primary memory. In computer systems, caching accelerates access by temporarily storing copies of frequently used information in faster storage layers, but without effective invalidation, caches risk delivering stale that can compromise application correctness and performance. This mechanism is essential across diverse domains, including processor caches in multiprocessor architectures, where it maintains by propagating invalidations to prevent conflicting copies of shared ; database systems, to refresh query results; and distributed or mobile environments, where intermittent connectivity and limited bandwidth exacerbate consistency challenges. Cache invalidation is widely regarded as one of the hardest problems in —as net developer Phil Karlton famously quipped, "There are only two hard things in Computer Science: cache invalidation and naming things"—stemming from the need to balance timeliness of updates, overhead costs, and without introducing race conditions or excessive network traffic. Common strategies for cache invalidation include time-based expiration, where entries are automatically discarded after a predefined interval; write-through or write-back policies, which synchronize updates directly to the source and invalidate affected cache lines; and invalidation reports, often broadcast in wireless or client-server setups to notify clients of changes without requiring constant polling. In web caching scenarios, techniques like purging specific URLs or banning patterns ensure fresh content delivery, particularly in content delivery networks (CDNs) handling dynamic sites. Research highlights that optimal invalidation depends on factors such as update frequency, disconnection patterns, and data access locality, with directory-based protocols in shared-memory systems showing efficiency using limited pointers per entry to track and invalidate copies. Advances continue to focus on scalable algorithms, such as bit-sequence reports for mobile databases, to minimize false invalidations and query latency while conserving resources.

Fundamentals

Definition and Purpose

Cache invalidation is the process of identifying and removing or updating outdated in a cache to ensure it reflects the most current information from the source. This mechanism is essential in systems where caches temporarily store copies of to accelerate access, but must be synchronized with changes in the underlying source to avoid discrepancies. The primary purpose of cache invalidation is to maintain data consistency across systems, thereby reducing errors caused by serving stale and balancing the advantages of caching with the need for reliability. In applications such as web servers and proxies, it ensures clients receive the newest content rather than outdated versions stored in the cache. Similarly, in databases and distributed systems, it aligns cached entries with the source of truth to prevent inconsistencies that could arise from data mutations. In content delivery networks (CDNs), invalidation removes cached content before its natural expiration, prompting fetches of updated data from backend servers on subsequent requests. The basic caching lifecycle involves checking the cache for requested : on a , the cached version is served quickly to reduce latency and load on primary storage; on a miss, is fetched from the source, stored in the cache for future use, and then served. However, without invalidation, subsequent requests could retrieve obsolete if the source has been modified, necessitating this step as a counterpart to cache and misses to uphold system integrity. Key benefits of effective cache invalidation include enhanced through the delivery of fresh, accurate data and the prevention of cascading errors in distributed systems, where stale cache entries might propagate incorrect information across components. Strategies for cache invalidation generally fall into explicit approaches, which directly trigger updates upon detected changes, or implicit ones, which rely on indirect mechanisms like periodic checks.

Historical Development

The roots of cache invalidation trace back to the early development of systems in the , where mechanisms were needed to manage inconsistencies in address spaces during paging operations. , invented in the early , allowed programs to use more memory than physically available by swapping pages between main memory and disk, requiring invalidation of entries for absent pages to ensure correct address translation and prevent access errors. Concurrently, the concept of cache memory itself was formalized in 1965 by , who described "slave memories" as fast buffers holding subsets of main memory data, implicitly necessitating invalidation strategies to update or evict stale entries based on access patterns. Advancements in the 1980s and 1990s extended cache invalidation to networked and database environments. The (DNS) introduced time-to-live (TTL) values in 1987 via RFC 1035, defining a 32-bit integer in resource records to specify how long cached entries remain valid before expiration and revalidation from authoritative sources, providing an early standardized approach to implicit invalidation in distributed name resolution. In database systems during this period, cache coherence protocols emerged for multiprocessors, with surveys highlighting invalidation-based schemes to maintain data consistency across shared caches, as seen in early implementations for systems like IBM's IMS hierarchical database, which incorporated buffer invalidation to handle data updates in multi-user environments. Web caching saw formalization with HTTP/1.0 in 1996 (RFC 1945), introducing headers like Expires for explicit staleness timestamps and Pragma: no-cache to force revalidation, enabling browsers and proxies to invalidate cached responses systematically. Key milestones in the late 1990s included the rise of content delivery networks (CDNs), where Akamai, founded in 1998, pioneered explicit invalidation methods to purge or refresh cached web content across global edge servers, addressing scalability challenges in dynamic content delivery. The shift to distributed systems post-2000, driven by cloud computing's demands for and low latency, further evolved invalidation techniques, emphasizing event-driven approaches over simple timeouts. In modern databases, event-driven invalidation gained prominence with Redis's initial release in 2009, which included pub/sub messaging from the outset to notify subscribers of data changes, enabling proactive cache updates in distributed setups like architectures. Post-2010 developments have integrated for predictive cache management and invalidation, optimizing performance in dynamic environments such as next-generation wireless networks and platforms. For instance, as of 2025, research has focused on cache invalidation taxonomies for reducing query latency in mobile and networks, alongside declarative methods to decouple from caching in . This progression reflects broader drivers from single-node to scalable, fault-tolerant systems, prioritizing consistency in increasingly complex environments.

Invalidation Strategies

Explicit Invalidation

Explicit invalidation is a cache management strategy wherein applications or components actively initiate the removal or update of targeted cache entries immediately following modifications to the underlying data source. This process typically involves the application code issuing direct signals, such as calls, to the cache layer to mark specific entries as invalid, ensuring that subsequent requests fetch fresh data from the authoritative store. This approach proves especially effective in write-heavy systems, including platforms, where data updates are frequent and predictable, such as alterations in product inventory that require invalidating caches for related items like pricing information. By integrating invalidation logic directly into the application , developers can maintain data consistency without relying on periodic checks or broadcasts. A key benefit of explicit invalidation is its granular control, which allows systems to invalidate only the precise entries affected by a change, thereby avoiding broad cache clearances that could degrade performance through increased miss rates and backend load. This targeted nature reduces bandwidth overhead compared to less selective methods and supports efficient handling of dynamic content in multitiered architectures. Unlike reactive implicit strategies that depend on timers or events for eviction, explicit invalidation enables proactive, application-orchestrated maintenance to uphold freshness in high-update scenarios.

Implicit Invalidation

Implicit invalidation refers to automated processes that remove or update stale cache entries based on predefined system-level rules or events, without requiring direct commands from the application or user. This approach contrasts with explicit invalidation, which relies on targeted triggers to remove specific entries. In implicit strategies, the cache handles detection and independently, ensuring data freshness through passive mechanisms rather than active intervention. The core mechanism of implicit invalidation depends on built-in rules such as timers for expiration or hooks that respond to resource constraints. For instance, entries may be automatically invalidated when a time-to-live (TTL) period elapses, or through eviction policies like least recently used (LRU) when exceeds defined limits. In distributed systems, these rules operate locally across nodes, avoiding the need for coordinated signaling. Examples include cache eviction in response to full capacity in WebSphere environments or TTL-based refreshes in large-scale social graph caches. This strategy is particularly suited for read-heavy workloads with unpredictable update patterns, such as feeds or streams like stock quotes and weather updates, where monitoring every modification for precise invalidation would be inefficient or infeasible. In such scenarios, the high volume of reads benefits from persistent caching, while implicit rules handle occasional staleness without complex tracking. Advantages of implicit invalidation include reduced developer overhead, as applications do not need to implement or manage explicit invalidation logic, and improved in distributed environments by eliminating centralized messaging that could become a bottleneck. For example, in clustered systems like WebSphere Portal, implicit timeouts and LRU evictions prevent overflow without propagating invalidations across JVMs, while in Facebook's system, TTL expiry supports consistent access to data across data centers without excessive coordination. This hands-off automation enhances reliability under varying loads, though it may tolerate brief staleness periods. Implicit invalidation encompasses types such as time-based expiry, where entries are discarded after a fixed duration, and event-driven updates, where events like memory limits trigger removals, all emphasizing automated, rule-based management over manual control.

Explicit Invalidation Techniques

Purge

is a straightforward explicit invalidation technique that involves the immediate and complete removal of specific cache entries, compelling the to retrieve fresh from the underlying source on the next access request. In this process, the cache provider deletes the targeted items without retaining any stale versions, ensuring that subsequent reads trigger a full re-fetch from the authoritative . This method is widely implemented in key-value caching systems, where operations like the DELETE command in allow clients to specify and remove individual keys directly from the server. For instance, in web applications storing user sessions in , purging the upon user logout invalidates the cached data to mitigate risks, such as unauthorized access to sensitive session information if the cache were to persist beyond the session's validity. The primary advantages of purging include its simplicity and rapid execution, as it requires minimal coordination and directly enforces cache consistency without ongoing monitoring. However, a key drawback is the potential for the , where multiple concurrent requests for the now-missing cache entry simultaneously overload the backend source, leading to performance bottlenecks. As a result, is best suited for scenarios with small-scale deployments or infrequent updates, where the risk of mass re-fetches remains low. A prominent real-world application is the PURGE HTTP method in Cache, a high-performance that uses this mechanism to discard specific objects and their variants from the cache, enabling precise control over content delivery in web environments.

Refresh

The refresh technique in cache invalidation proactively fetches and replaces stale in the cache upon an invalidation trigger, such as a data update, to maintain current content without requiring a subsequent read to repopulate the entry. This process ensures the cache remains populated and avoids immediate misses, differing from purge methods that simply evict entries for later re-fetching. A key implementation is the write-through strategy, where write operations update both the primary data source and the cache simultaneously, propagating changes in real-time to keep the cache synchronized. In database systems like Hibernate, entity updates trigger invalidation of dependent query cache entries; the cache is then refreshed by re-executing the query and loading updated data from the database on the next access. This approach offers advantages in maintaining high cache hit rates for frequently accessed, semi-static data—such as configuration files—by ensuring freshness without eviction-induced latency, though it incurs higher write latency due to dual updates and risks amplifying write throughput under heavy modification loads. Variants include background refresh, where updates occur asynchronously to reduce foreground impact; for instance, in browser caches, ETag validation enables conditional requests that refresh the entry only if the server's entity tag mismatches the cached one, minimizing unnecessary transfers.

Invalidation Messaging

Invalidation messaging is a technique in explicit cache invalidation that employs message queues or publish-subscribe (pub/sub) systems to propagate invalidation signals across nodes, ensuring coordinated updates when underlying data changes. In this process, an update to the data source triggers the publication of an invalidation message—such as "invalidate key X"—to a designated topic or queue. Cache instances subscribed to this channel receive the message and promptly remove or mark the affected entries as stale, thereby maintaining consistency without requiring direct point-to-point communication between nodes. This approach is particularly suited for distributed environments where caches are replicated across multiple servers or regions. In architectures, implementation typically involves an update service or publishing invalidation to a pub/sub system, which are then consumed by cache layers such as Cluster. For instance, when a microservice modifies data, it emits a targeted via a broker like or Amazon SQS, allowing downstream cache nodes to process the invalidation asynchronously and evict specific keys. This decouples the update logic from cache management, enabling scalable propagation in large-scale systems where direct cache access is impractical. pub/sub, for example, facilitates this by allowing channels to broadcast to multiple subscribers within a cluster, supporting high-throughput invalidation without disrupting ongoing operations. The advantages of invalidation messaging include enhanced in distributed systems, as it allows a single update to efficiently notify numerous cache instances, and supports models by tolerating temporary staleness during propagation. However, it introduces network overhead from message routing and potential risks like message loss or duplication if the broker fails, necessitating robust retry mechanisms and acknowledgments to ensure reliability. These trade-offs make it ideal for high-availability setups but require careful tuning to balance latency and consistency. A notable example is Netflix's EVCache, a distributed in-memory cache deployed in the for multi-regional resiliency. In this system, a write operation in one region triggers an invalidation message sent via Amazon SQS to the corresponding cache in another region, prompting eviction of the stale entry and ensuring cross-regional consistency without synchronous coordination. This messaging-based approach enabled Netflix to handle asynchronous updates across global data centers while minimizing downtime.

Implicit Invalidation Approaches

Time-Based Expiry

Time-based expiry is an implicit invalidation approach in which cache entries are assigned a time-to-live (TTL) value upon insertion or update, after which the cache automatically evicts the entry without requiring explicit signals from the data source. This process ensures by discarding potentially stale data after a fixed duration, allowing subsequent requests to fetch fresh content from the origin. In practice, systems like implement this via the EXPIRE command, which sets the TTL in seconds for a given key, marking it as volatile, with the key deleted lazily when accessed if expired or during periodic background processes that check for expired keys. The mechanism operates independently of data changes, relying solely on wall-clock time to manage cache freshness. Selecting an appropriate TTL involves balancing cache hit rates against data staleness, often guided by the heuristic that TTL should approximate the inverse of the expected update frequency of the underlying data. For instance, if data updates occur on average every 5 minutes, a TTL of around 300 seconds can minimize unnecessary evictions while preventing prolonged staleness; this is derived from estimating the update rate λ as the inverse of the inter-update interval, then setting TTL ≈ 1/λ to align with typical change patterns observed in web caching workloads. Such selection prioritizes empirical analysis of access and update logs to optimize , as overly short TTLs increase origin load, while long ones risk serving outdated information. This strategy offers simplicity and low overhead, as it requires no inter-system coordination or event , making it suitable for distributed caches where tracking updates is challenging. However, it can result in serving slightly stale data if updates occur just before expiry or cause premature evictions for infrequently changing items, leading to higher miss rates and computational costs during irregular update patterns. Prominent examples include the HTTP Cache-Control header's max-age directive, which specifies the freshness lifetime in seconds for cached responses, enabling browsers and proxies to automatically expire entries without revalidation requests. Similarly, DNS resource records use TTL fields, defined as 32-bit integers in seconds, to control how long resolvers cache mappings like IP addresses before requerying authoritative servers, as standardized in the protocol. For dynamic content like news feeds, a 5-minute TTL is commonly applied to balance timeliness with reduced backend queries.

Event-Driven Updates

Event-driven updates represent an implicit cache invalidation strategy where system events, such as data modifications or writes, automatically trigger the removal or updating of affected cache entries to maintain consistency. This process relies on observers, hooks, or notification mechanisms that detect changes in the underlying data source—such as database operations or alterations—and propagate invalidation signals to the cache layer. For instance, when a write operation occurs, an event listener identifies the impacted cache keys and evicts them, ensuring subsequent reads fetch fresh data from the source. In practice, this approach is implemented through integrated event-handling frameworks. In distributed file systems like NFS version 4, a 64-bit change attribute (i_version) is incremented on every file modification that would update the ctime, enabling client-side caches to compare attributes and invalidate stale entries upon detecting discrepancies. Similarly, in in-memory data grids such as , near caches on client nodes are configured to receive cluster-wide events from server nodes; when a data update occurs, these events automatically invalidate or refresh the local near-cache entries, supporting transactional consistency without manual intervention. Compared to time-based expiry, event-driven updates offer greater precision for dynamic datasets by responding only to actual changes, reducing unnecessary cache misses and improving data freshness. However, they introduce setup complexity due to the need for reliable event propagation and coordination across distributed components, and they risk incomplete invalidations if events are missed or delayed. In high-throughput scenarios, the volume of events can also impose additional overhead on the system. A notable variant is write-back caching with batched invalidations, where updates are initially applied to the cache for low-latency writes, followed by asynchronous batching to the persistent store; invalidation events are then triggered in groups upon batch completion to synchronize caches efficiently while minimizing individual event processing costs.

Challenges and Solutions

Consistency Problems

Cache inconsistency arises when cached data becomes stale relative to the authoritative source, leading to reads that return outdated information. This problem, often termed stale reads, occurs because invalidation mechanisms fail to promptly update or remove affected cache entries across distributed systems. For instance, in dynamic environments like platforms, users may view incorrect item prices or availability if caches are not synchronized in time. Such inconsistencies can propagate errors throughout the system, undermining user trust and application reliability. Lost updates represent another critical issue, where race conditions during concurrent operations cause valid changes to be overwritten or ignored. In a typical , multiple clients read the same cached value, perform local updates based on that stale data, and then write back, resulting in one update being lost as it overwrites a more recent change from the source. This is particularly prevalent in write-heavy distributed setups, where asynchronous invalidations exacerbate timing mismatches. Cache stampedes, also known as the , emerge when a popular cache entry expires simultaneously for many clients, triggering a flood of requests to the backend source and overwhelming it, which delays recovery and amplifies inconsistency windows. These problems stem from several causes in distributed environments. Network partitions isolate cache nodes from invalidation signals, allowing divergent data states to persist until reconnection. Asynchronous invalidation delays, common in event-driven systems, create temporary lapses where updates propagate unevenly across replicas. Incomplete coverage in multi-cache architectures, such as when not all edge caches receive notifications, leaves pockets of stale data unaddressed. Both explicit and implicit invalidation strategies can contribute to these issues if propagation is unreliable. Distributed caches often operate under models, where updates propagate asynchronously and all replicas eventually converge, contrasting with that guarantees immediate synchronization at the cost of higher latency. In practice, eventual consistency tolerates brief inconsistencies for better availability, but in high-stakes applications like auctions, it can lead to discrepancies. Detection techniques include cache versioning, where entries store monotonically increasing version numbers or timestamps compared against the source to flag staleness, and checksums like ETags that enable conditional validation requests to confirm freshness without full data transfer. These methods allow systems to proactively identify and resolve inconsistencies, though they introduce overhead in validation checks.

Performance Trade-offs

Cache invalidation introduces performance overheads across multiple dimensions, including CPU cycles expended on executing invalidation logic such as dependency resolution or coherence maintenance in shared-memory systems. In distributed environments, network costs arise from or multicasting invalidation messages to remote caches, consuming bandwidth and introducing latency. Refreshing invalidated entries further imposes I/O overhead by requiring reads from the underlying data source, which can bottleneck throughput in high-load scenarios. A core trade-off in cache invalidation balances these costs—often expressed as the product of invalidation frequency and per-operation time—against the risk of staleness, where delayed updates may propagate outdated data and impair application reliability. Frequent invalidations minimize staleness but amplify , while infrequent ones reduce overhead at the expense of potential consistency violations. To optimize these trade-offs, several techniques mitigate overhead without fully sacrificing freshness. Lazy invalidation defers actual entry removal until the next access, avoiding proactive scans or evictions and thus lowering immediate CPU and I/O demands. Probabilistic invalidation applies sampling to invalidate only a representative of entries, scaling efficiently for massive caches where deterministic approaches would incur excessive computation. Hybrid explicit-implicit models combine targeted explicit purges for high-priority with background implicit expiry for others, enabling fine-tuned based on access patterns and consistency requirements. Key performance metrics highlight these dynamics, such as post-invalidation hit rate drops due to repopulation latency, which can increase miss rates in bursty workloads before stabilizing. The Caffeine library exemplifies effective balancing, integrating a Window TinyLFU admission policy with LRU eviction to sustain high hit rates while delivering sub-millisecond latencies in concurrent environments. Addressing in large-scale deployments involves batching invalidations to amortize network and CPU costs across multiple entries in a single message or cycle. Bloom filters further aid by providing approximate membership queries to filter irrelevant invalidations, enabling efficient targeting in systems with billions of keys without exhaustive lookups. Recent advances, such as bounded staleness protocols like Skybridge (introduced in 2025), provide configurable consistency guarantees with minimal overhead in distributed caches.

References

  1. https://redisson.pro/glossary/cache-invalidation.html
  2. https://www.geeksforgeeks.org/system-design/cache-invalidation-and-the-methods-to-invalidate-cache/
  3. https://pages.cs.wisc.edu/~ragh/Qualfiles/(3.2.2)%20Cache%20Invalidation%20patterns.html
  4. https://dl.acm.org/doi/10.1145/1821748.1821815
  5. https://martinfowler.com/bliki/TwoHardThings.html
  6. https://ieeexplore.ieee.org/document/1369180
  7. https://www.varnish-software.com/resources/documentation/glossary-old/what-is-cache-invalidation/
  8. https://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=2172&context=cstech
  9. https://ieeexplore.ieee.org/document/11006088
  10. https://redis.io/glossary/cache-invalidation/
  11. https://engineering.fb.com/2022/06/08/core-infra/cache-made-consistent/
  12. https://cloud.google.com/cdn/docs/cache-invalidation-overview
  13. http://www.csapp.cs.cmu.edu/2e/ch9-preview.pdf
  14. https://www.semanticscholar.org/paper/Slave-Memories-and-Dynamic-Storage-Allocation-Wilkes/22e6acfbc4af9ddc104965816dc20735374c7bad
  15. https://datatracker.ietf.org/doc/html/rfc1035
  16. https://web.mit.edu/6.173/www/currentsemester/readings/R04-cache-coherence-survey-1990.pdf
  17. https://datatracker.ietf.org/doc/html/rfc1945
  18. https://redis.io/docs/latest/develop/pubsub/
  19. https://www.frontiersin.org/journals/artificial-intelligence/articles/10.3389/frai.2025.1441250/full
  20. https://journals.uran.ua/eejet/article/view/325932
  21. https://sigmodrecord.org/publications/sigmodRecord/0012/yuen.pdf
  22. https://dl.acm.org/doi/10.5555/1287369.1287418
  23. https://dl.acm.org/doi/pdf/10.1145/316188.316219
  24. https://dl.acm.org/doi/pdf/10.1145/369275.369282
  25. https://publib.boulder.ibm.com/httpserv/cookbook/WebSphere_Application_Server-WAS_traditional-Dynamic_Cache.html
  26. https://www.usenix.org/sites/default/files/conference/protected-files/srecon15europe_slides_mihaljevic.pdf
  27. https://aws.amazon.com/builders-library/caching-challenges-and-strategies/
  28. https://varnish-cache.org/docs/trunk/users-guide/purging.html
  29. https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
  30. https://info.varnish-software.com/blog/cache-invalidation-in-varnish
  31. https://www.designgurus.io/blog/cache-invalidation-strategies
  32. https://hazelcast.com/blog/a-hitchhikers-guide-to-caching-patterns/
  33. https://redisson.pro/glossary/write-through-and-write-behind-caching.html
  34. https://docs.jboss.org/hibernate/orm/current/userguide/html_single/Hibernate_User_Guide.html#pc-query-cache
  35. https://aws.amazon.com/caching/best-practices/
  36. https://www.ehcache.org/documentation/2.8/apis/write-through-caching.html
  37. https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching
  38. https://redis.io/glossary/pub-sub/
  39. https://sigops.org/s/conferences/hotos/2025/papers/hotos25-426.pdf
  40. https://blog.devops.dev/design-and-implementation-of-distributed-caching-strategy-with-redis-in-microservices-architecture-4932fa2fe92e
  41. https://techblog.netflix.com/2013/12/active-active-for-multi-regional.html
  42. https://redis.io/commands/expire
  43. https://bslee.w3.uvm.edu/papers/WebCaching_WISE02.pdf
  44. https://datatracker.ietf.org/doc/html/rfc7234#section-5.2.2.8
  45. https://datatracker.ietf.org/doc/html/rfc1035#section-3.2.1
  46. https://daily.dev/blog/cache-invalidation-vs-expiration-best-practices
  47. https://docs.oracle.com/middleware/1213/toplink/solutions/qcn.htm
  48. https://lwn.net/Articles/975863/
  49. https://www.gridgain.com/docs/gridgain8/latest/developers-guide/near-cache
  50. https://www.usenix.org/system/files/conference/atc13/atc13-holland.pdf
  51. https://dl.acm.org/doi/10.1145/74851.74870
  52. https://dl.acm.org/doi/10.1145/261124.261125
  53. https://dl.acm.org/doi/10.1145/2926965
  54. https://dl.acm.org/doi/pdf/10.5555/1515984.1515986
  55. https://dl.acm.org/doi/10.1145/2380403.2380433
  56. https://mcn.cse.psu.edu/paper/gcao/TKDE03.pdf
  57. https://www.usenix.org/system/files/fast23-yang.pdf
  58. https://wolle.science/publications/wingerath-2020-icde-speed-kit.pdf
  59. https://cseweb.ucsd.edu/~avattani/papers/cache_stampede.pdf
  60. https://www.researchgate.net/publication/50946124_A_Hybrid_Cache_Invalidation_Technique_for_Data_Consistency_in_MANET
  61. https://dl.acm.org/doi/10.1145/3149371
  62. https://people.cs.vt.edu/~irchen/6204/paper/TAN01-slide.pdf
  63. https://dl.acm.org/doi/10.1145/3465998.3466002
  64. https://www.usenix.org/conference/osdi25/presentation/lyerly
Add your contribution
Related Hubs
User Avatar
No comments yet.