Cache vs. Session Store

Scale globally while maintaining low latency and cache more efficiently to lower costs: Click here to talk with the Redis Enterprise team.

There’s a saying, “In Silicon Valley you can throw a rock in any direction and you’ll probably hit a software engineer.” The other day I was traveling by train from San Jose to San Francisco when I overheard two software engineers comparing the speed of the products they were developing. When I heard one developer say, “Our app runs fast because we cache all the session data,” I realized that even a Silicon Valley engineer may be unaware of the subtle differences between a cache and a session store. Redis, as an in-memory database, is used for both caching and session store scenarios. Let’s look at how the use cases differ.

Cache

An application stores data in the cache to serve future requests faster. Typically, the cache storage is located in the RAM and has sub millisecond latency.

In the data fetch lifecycle, the application first looks for the data in the cache. If there’s a hit (i.e. the data is in the cache), it serves the data instantaneously. Conversely, if there’s a miss it fetches the data from a permanent store, stores a copy in the cache, and serves the data to the consumer. For all future requests, the data is already there in the cache and is served faster. When an application updates the data, it updates both the cache and the permanent store.

This lifecycle works well for scenarios where different consumers request the same data over a period of time. One should also note that the data is stored at the application level, and not at the user level. So the data that’s stored in the cache is shared among users. Images, videos, static HTML pages, JavaScript libraries and style sheets are examples of data that are often stored in cache.

Session Store

A session-oriented application (a web application, for example) starts a session when a user logs in, and is active until the user logs out or the session times out. During this period, the application stores all session-related data either in the main memory or in a session store—a database that doesn’t lose the data when the application goes down. Session data may include user profile information, messages, personalized data and themes, recommendations, targeted promotions and discounts, etc.