Skip to main content


BehavioralPerformanceCloud distributedAbout 4 min


The caching pattern avoids expensive re-acquisition of resources by not releasing them immediately
after use. The resources retain their identity, are kept in some fast-access storage, and are
re-used to avoid having to acquire them again.


Real world example

A team is working on a website that provides new homes for abandoned cats. People can post their
cats on the website after registering, but all the new posts require approval from one of the
site moderators. The user accounts of the site moderators contain a specific flag and the data
is stored in a MongoDB database. Checking for the moderator flag each time a post is viewed
becomes expensive and it's a good idea to utilize caching here.

In plain words

Caching pattern keeps frequently needed data in fast-access storage to improve performance.

Wikipedia says:

In computing, a cache is a hardware or software component that stores data so that future
requests for that data can be served faster; the data stored in a cache might be the result of
an earlier computation or a copy of data stored elsewhere. A cache hit occurs when the requested
data can be found in a cache, while a cache miss occurs when it cannot. Cache hits are served by
reading data from the cache, which is faster than recomputing a result or reading from a slower
data store; thus, the more requests that can be served from the cache, the faster the system

Programmatic Example

Let's first look at the data layer of our application. The interesting classes are UserAccount
which is a simple Java object containing the user account details, and DbManager interface which handles
reading and writing of these objects to/from database.

public class UserAccount {
  private String userId;
  private String userName;
  private String additionalInfo;

public interface DbManager {

  void connect();
  void disconnect();
  UserAccount readFromDb(String userId);
  UserAccount writeToDb(UserAccount userAccount);
  UserAccount updateDb(UserAccount userAccount);
  UserAccount upsertDb(UserAccount userAccount);

In the example, we are demonstrating various different caching policies

  • Write-through writes data to the cache and DB in a single transaction
  • Write-around writes data immediately into the DB instead of the cache
  • Write-behind writes data into the cache initially whilst the data is only written into the DB
    when the cache is full
  • Cache-aside pushes the responsibility of keeping the data synchronized in both data sources to
    the application itself
  • Read-through strategy is also included in the aforementioned strategies and it returns data from
    the cache to the caller if it exists, otherwise queries from DB and stores it into the cache for
    future use.

The cache implementation in LruCache is a hash table accompanied by a doubly
linked-list. The linked-list helps in capturing and maintaining the LRU data in the cache. When
data is queried (from the cache), added (to the cache), or updated, the data is moved to the front
of the list to depict itself as the most-recently-used data. The LRU data is always at the end of
the list.

public class LruCache {

  static class Node {
    String userId;
    UserAccount userAccount;
    Node previous;
    Node next;

    public Node(String userId, UserAccount userAccount) {
      this.userId = userId;
      this.userAccount = userAccount;
  /* ... omitted details ... */

  public LruCache(int capacity) {
    this.capacity = capacity;

  public UserAccount get(String userId) {
    if (cache.containsKey(userId)) {
      var node = cache.get(userId);
      return node.userAccount;
    return null;

  public void set(String userId, UserAccount userAccount) {
    if (cache.containsKey(userId)) {
      var old = cache.get(userId);
      old.userAccount = userAccount;
    } else {
      var newNode = new Node(userId, userAccount);
      if (cache.size() >= capacity) {"# Cache is FULL! Removing {} from cache...", end.userId);
        cache.remove(end.userId); // remove LRU data from cache.
      } else {
      cache.put(userId, newNode);

  public boolean contains(String userId) {
    return cache.containsKey(userId);
  public void remove(Node node) { /* ... */ }
  public void setHead(Node node) { /* ... */ }
  public void invalidate(String userId) { /* ... */ }
  public boolean isFull() { /* ... */ }
  public UserAccount getLruData() { /* ... */ }
  public void clear() { /* ... */ }
  public List<UserAccount> getCacheDataInListForm() { /* ... */ }
  public void setCapacity(int newCapacity) { /* ... */ }

The next layer we are going to look at is CacheStore which implements the different caching

public class CacheStore {

  private static final int CAPACITY = 3;
  private static LruCache cache;
  private final DbManager dbManager;

  /* ... details omitted ... */

  public UserAccount readThrough(final String userId) {
    if (cache.contains(userId)) {"# Found in Cache!");
      return cache.get(userId);
    }"# Not found in cache! Go to DB!!");
    UserAccount userAccount = dbManager.readFromDb(userId);
    cache.set(userId, userAccount);
    return userAccount;

  public void writeThrough(final UserAccount userAccount) {
    if (cache.contains(userAccount.getUserId())) {
    } else {
    cache.set(userAccount.getUserId(), userAccount);

  public void writeAround(final UserAccount userAccount) {
    if (cache.contains(userAccount.getUserId())) {
      // Cache data has been updated -- remove older
      // version from cache.
    } else {

  public static void clearCache() {
    if (cache != null) {

  public static void flushCache() {"# flushCache...");

  /* ... omitted the implementation of other caching strategies ... */


AppManager helps to bridge the gap in communication between the main class and the application's
back-end. DB connection is initialized through this class. The chosen caching strategy/policy is
also initialized here. Before the cache can be used, the size of the cache has to be set. Depending
on the chosen caching policy, AppManager will call the appropriate function in the CacheStore

public final class AppManager {

  private static CachingPolicy cachingPolicy;
  private final DbManager dbManager;
  private final CacheStore cacheStore;

  private AppManager() {

  public void initDb() { /* ... */ }

  public static void initCachingPolicy(CachingPolicy policy) { /* ... */ }

  public static void initCacheCapacity(int capacity) { /* ... */ }

  public UserAccount find(final String userId) {"Trying to find {} in cache", userId);
    if (cachingPolicy == CachingPolicy.THROUGH
            || cachingPolicy == CachingPolicy.AROUND) {
      return cacheStore.readThrough(userId);
    } else if (cachingPolicy == CachingPolicy.BEHIND) {
      return cacheStore.readThroughWithWriteBackPolicy(userId);
    } else if (cachingPolicy == CachingPolicy.ASIDE) {
      return findAside(userId);
    return null;

  public void save(final UserAccount userAccount) {"Save record!");
    if (cachingPolicy == CachingPolicy.THROUGH) {
    } else if (cachingPolicy == CachingPolicy.AROUND) {
    } else if (cachingPolicy == CachingPolicy.BEHIND) {
    } else if (cachingPolicy == CachingPolicy.ASIDE) {

  public static String printCacheContent() {
    return CacheStore.print();

  /* ... details omitted ... */

Here is what we do in the main class of the application.

public class App {

  public static void main(final String[] args) {
    boolean isDbMongo = isDbMongo(args);
    if(isDbMongo){"Using the Mongo database engine to run the application.");
    } else {"Using the 'in Memory' database to run the application.");
    App app = new App(isDbMongo);
    String splitLine = "==============================================";;

  public void useReadAndWriteThroughStrategy() {"# CachingPolicy.THROUGH");

    var userAccount1 = new UserAccount("001", "John", "He is a boy.");;;

  public void useReadThroughAndWriteAroundStrategy() { /* ... */ }

  public void useReadThroughAndWriteBehindStrategy() { /* ... */ }

  public void useCacheAsideStategy() { /* ... */ }

Class diagram

alt text


Use the Caching pattern(s) when

  • Repetitious acquisition, initialization, and release of the same resource cause unnecessary
    performance overhead.