Ephemeral Storage Layer

Although basic 3 tier architecture described above addresses the performance challenge, the performance is a characteristic, which can almost always be improved. Ephemeral storage is used for caching data that is frequently accessed. Source data is always kept in persistent storage such as relational data store. Ephemeral storage layer needs to support Atomicity, Consistency and Isolation without having to take care of Durability property.

Let’s consider the following scenario: We have a relational data store. We notice that certain read-only transactions are executed frequently. These transactions require that the server computes the result over and over, even if the resulting data set has not been changed.

How can we improve this situation? We can deploy a server that can store the result of this query in memory and return the result without the need to run the query again. There are several in-memory data stores designed specifically for such use cases, the most notable are: Redis, RocksDB, Memcached. This strategy is often used in modern storage layer design. A well designed cache server integration would result in an order of magnitude performance improvement.

Bear in mind that a relational data store is in general well optimised in how they use cache internally, so using a cache server for single key lookup transactions would not necessarily produce the desired performance improvements. The real goal is to store frequently read transaction results and update the cached versions only if the result set has changed.

This allows to reduce latency since response is already available to be retrieved from the cache server. This also improves throughput since there is no more overhead of computing the result of the query on the data store side, which allows it to execute more transactions per given unit of time. This is a straight win situation!