Writing to the Cache

Here is how HopPress handles a request for a post once the cache is in place:

sequenceDiagram
    autonumber
    participant App as Application
    participant Cache as Cache
    participant DB as Database

    App->>Cache: Request data (e.g., Get post:123)
    alt Cache Hit
        Cache-->>App: Return cached data
    else Cache Miss
        Cache-->>App: Data not found
        App->>DB: Query database for data
        DB-->>App: Return data from database
        App->>Cache: Store data in cache
    end

This is called the cache-aside pattern. The application is responsible for reading and writing the cache. There are other patterns, but cache-aside is the simplest and most common. It is also called lazy loading, because the cache is filled only when a request asks for a key that is not in the cache.

Eviction

A cache has limited capacity. When it fills up, new writes must replace some of the existing entries. This is called eviction.

The cache picks which entries to remove according to an eviction policy. The common policies are:

• Least Recently Used (LRU): Removes the entries that were read least recently.
• Least Frequently Used (LFU): Removes the entries that were read the fewest times.
• First In, First Out (FIFO): Removes the entries that were added to the cache first.
• Random: Removes entries at random.

The right eviction policy depends on the access pattern of the data. For HopPress, I would choose LRU. It keeps the recently read posts in the cache, and those are the posts most likely to be read again.