Designing Cache Architecture
Published: 2022-01-15 10:33:47

---
title: Designing Cache Architecture
published: true
description: 
tags: 
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q95zydz1qrndthxse7is.png
canonical_url: https://iamvp7.github.io/designing-cache-architecture
---

Many software developers might have read about various architecture, among them for some Clean Architecture if favorite.  The idea behind this architecture is as we move to the inner layers, it should not have any dependency from the external layer.

Recently in our team, we were planning to having casual interaction to introduce caching system; to reduce the text-based look-up from our SQL Database.  Our main goal was 


1. Have good Developer Experience to new Developers to use system
2. Should be easier to introduce newer cache at any point in future

![Cache Implementation Diagration](https://cdn.hashnode.com/res/hashnode/image/upload/v1642180916032/RoBf8nK-p.png)

Before moving to the details our hypothesis is as follows, at any point of time we will be having only one Distributed cache (Redis or DynamoDB or something else). Even when we are having two different caches at the same time it is not going to be difficult to do the implementation.

We have 4 layers in our architecture

1. Cache Manager
2. Cache Connector
3. Cache System Connector
4. Physical Cache System

## Cache Manager


![business-cache.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1642232711899/2xBweHEti.png)

Cache Manager is the first layer of our Cache Architecture. Via this layer, other parts of the system will interact. And the methods which connect with the Cache API Connector are available here.

### Cache connector and Cache methods

Here we have used the Abstract factory method to decide which Cache Layer (Redis, DynamoDB, or anything else) to connect on. We have also implemented the methods Cache API connecting methods in this layer with validations (checking NotNull for Key & Value).

### External System Connector

This is the Class where external components of the system connect to Connect with the Cache System to insert into Cache or Get value from Cache. 


![whole-architecture.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1642234097213/2Xok_-lZ_.png)


## Cache Connector

Once the Cache Manager decides which Cache System to connect with we will be moving to the next layer called Cache Connector or Cache API connector (Both names are interchangeable).

Let's take DynamoDB as our Cache System. So once CachceManager decides its DynamoDB, we will be moving to the DynamoDB API Connector layer. This layer will be extending a few methods from CacheConnector Class. 

### CacheConnector Class 
In general, will be having the generic methods in which we want to interact with Cache.

Say we will have methods to insert/get data as JSON or text or HashMap, drop the keys so on. Some Cache may have some methods, not all so the classes (DynamoAPIConnector or RedisAPIConnector) which extend this abstract CacheConnector Class will write a little tweaked version according to their system.

In Redis we will have something like HSet where we can give two keys to look up the value. While in RocksDB we may not have this, so we will have a different approach to combine these two keys into a single key with some logic.

###  DynamoDB Cache API connector

So as mentioned before this method will be extending the CacheConnector Class. From this class, we will be connecting with  DynamoDB System Connector which will have the core method and initialization logic.

In this DynamoDB Cache API connector class we will be extending the abstract methods from CacheConnector, and will be implemented according to the DynamoDB system method.

## DynamoDB Cache System Connector & Actual DynamoDB machine

Cache System Connector is the core class where we will be having things like initialization of Cache and other core methods to interact with the Physical Cache System.

We will be loading the IP connection URL, read timeout, maximum connection to the physical cache machine, and so on.



## What is easier?

The main goal of our design decision is to make it easy for any other new system to be pluggable and removable easily.

If anyone wants to plug new Cache system (with KV) then they have to make 3 modification
1) In DBManager have to add Object creation for new Cache API Connector
2) Class which extends Cache API Connector
3) Class which extends Cache System Connector 


## What is difficult?

One of the major things is, in case we need to manage two Cache systems then we have to write a new method at DBManager.

This design came up during our casual interaction, feel free to share your thoughts to it can help us or anyone to improve designing the system.

*All the logos are owned by the project companies*