Idea No. 4: Generic Cache Microservice

In general, a cache is stored data that is supposedly faster to access than building or getting the data from a data source each time it is requested. A cache microservice can be created with the pure purpose of managing caches which include creating them, storing them, expiring them and broadcasting events about them. Sounds good? Read on...

Most applications would have data that rarely change. Usually, these are lookup data like countries, states, names of months, names of days, product categories, etc. These types of data are easy candidates for caching. For some applications, the data can be a search result or a report, for which caching can help improve response times for the same search/report query. For some applications, a page can contain static data for a long time, and it may be faster to just cache the entire page instead of rendering it every time.

There's really nothing new about these. These are common problems and most applications would have implementations of these in varying degrees. However, micrososervices open up a new opportunity to create a generic or centralized caching mechanism for various, if not any, applications.

Security

The most important feature involves securing the cache, and to making sure that a cache is only available to the applications that are allowed to access it. The security features should support server, app, user and data level security, depending on the needs of the application using the cache microservice.

Creating a Cache

If a cache does not exist, it should be created. Applications can push data to the cache microservice. The cache microservice can also pull data from applications. Each cache should be assigned a globally unique key so that they can be accessed from the cache microservice.

Push

An application can push data to the cache microservice. The application must manage the pushed data explicitly.

Pull

A cache can be defined with a command that will let the cache microservice auto-pull data from an application and automatically (re-)create a requested cache.

Expiring a Cache

A cache can be given a default expiry date, time or age. When this expiry setting is met, the cache should automatically expire. If no expiry setting is set, the cache would have to be explicitly expired. Expiring a cache invalidates and removes it from the cache microservice's store. If a cache is expired, it needs to be re-created.

Any cache can be explicitly expired. Applications can send a special command to the cache microservice to expire a cache by its unique key, or perhaps all of the application's cache.

Accessing a Cache

If a cache is requested and it exists, it is returned. For pushed cache, the application should have a catch to create the cache when needed. For pulled cache, the cache microservice can automatically create it when needed.

Broadcasting Cache Events

The cache microservice should have a feature to broadcast when a cache expires and/or when a cache gets (re-)created. The broadcast can be to clients via SignalR. The broadcast can also be straight to the application's server, which is specially useful when the application pushes data to the cache microservice.

The ability of the cache microservice and the application to react to real-time events is important. If the correct sets of data are cached, it is highly likely that the application can enjoy improved UI rendering performance and reducing back-end server side accesses, which can help save on operation costs. Combined with client-side caching as well, further performance improvements can be achieved for the UX.

An example interaction can involve a website's product list. The list of products can be cached, in fact even the HTML to render them in a list. When a product maintenance UI adds/edits/deletes a product, it can include an instruction to send a command to the cache microservice that expires its cache of products. This can then trigger the broadcasting of the event to application clients and/or servers. The application can then choose to push data to the cache microservice. Or it can let the cache microservice pull data to re-create the cache automatically. If the product list is paged, all cached pages can also get updated, ready for the next requests. Thus, all existing and future clients are instantly updated with the latest product list in the cache microservice.

A generic cache microservice can be hosted as a generic instance for many applications. Or, the generic cache microservice can be hosted as an instance per application/system. The point is, it is possible for the cache microservice to be a product by itself, offered as a service for applications that need it.