Redis Cache

Caching in Microsoft technologies has many forms and options.  You can have server side cache, client side cache or downstream caching such as proxy servers.

Server Cache in .NET:

• in-Memory store: This type of server cache historically was very useful for maintaining state and having users tied to a collection of objects/knowledge and is extremely fast.  You need to think about multiple instances, or how to route traffic.  So you can tie a user to use static routing to ensure user Joe's session always goes to server 3.  But is server 3 dies, you loose all the cache data.  
• Local storage cache works well for larger amounts of data that are too big for memory cache but as they are storage based are much slower.
• Shared/ centralized caching, allows shared cache, a good example is using SQL server for caching and the user can go to any front end web server and the cache is pulled from SQL.  Allows for failure, no need to performed fixed user routing of requests (sticky sessions).  It is slower as cache is pulled from a central service that in turn goes into SQL to retrieve the data.
• Azure Redis cache is a form a of Shared Caching.  The cache is better if used in memory like Redis cache does.  A Redis Cache is a service that is optimized for performance and allows stateless caching to work across server instances.  So while it needs to travel over your network in Azure, it is not as fast as local cache but extremely fast for centralized caching.  Redis is pretty advanced and has clustering and replication to ensure performance is good.

https://docs.microsoft.com/en-us/azure/architecture/best-practices/caching

Client Side Cache:

• Browser can hold information in session but it is not secure or at least less secure than server side cache.
• CDN's are a way of retrieving data from an optimized central store but useful for static files and data.
• Adding headers to HTTP requests allow for downstream caching.  For example, I offer a REST API (e.g. C# Web API) that return a feature product that change hourly.  I could easily set expiry caching to 10 min.  The product is changed every 10 minutes for each user and added to the users local cache.  So if an average user is on for 20 minutes, they only to 2 of their 10 requests to the REST API, the other 8 calls are served locally.  Couple with Server caching, the requests to the server can be fast, with very few calls to the back-end database yet the relatively static data causes far less demand on the web service.
• Validation Caching - is client caching, that stores data locally, but a request is sent to the server to ask if there is a change, if there is a change send back the new data.  If the data has no changed, a 304 response is sent and the browser uses the previously stored local cached data.

Client and Server (Redis) side Caching on Azure

Note:  The diagram only outlines client caching referring to the browser or end device.  Using HTTP headers, you can also set down stream proxy caching.  This is also generally referred to as client caching.

Firefox has a nice short cut to check you client cache is working.  Open Firefox, and request the URL that shall cache a resource on the local client machine.  then in the URL type in "" and check what is being served up locally.

Basic Caching Options:
1. Client Cache (local) - saves on network call and serve side processing.  Can hold client specific static data.
2. Client Cache (proxy) - saves on server side processing.  Can only hold generic static data.
3. Server side Cache (Redis) - saves on computing resources by not having to connect to data sources on every request.  Useful for static share data.