Iff you ever work with CosmosDb and are concerned about high volume accesses:
CosmosDb is fast, no doubt, but because it’s never hosted in the same network as your app-services, Azure functions etc., there is still significant network lag. Because of this, it makes a huge difference to put a redis instance in front.
For me, in a current project, the performance gain was enormous: reads went down from 300-500ms to 50-100ms per read.
One caveat is this works well only for non-query reads - like “get this specific document”. For server-side queries, this doesn’t work. So depending on your usage, your mileage may vary. In my scenario, the non-query reads overwhelmingly outnumbered the query-reads statistically, so adding redis was a big win.
As for implementation, assuming you got something like an IRepository that abstracts access CosmosDb, you just add another implementation of IRepository, RedisCachingRepositoryDecorator. For each write this decorator also writes to the cache and for each read it first asks the cache; if it gets a hit, it returns that hit. If no (this should really only happen when Redis restarts or starts throwing out old data), it proceeds to ask CosmosDb, updates the cache and returns the result.
publicinterfaceICache// this interface is a custom abstraction over the cache that's not as Redis-specific as IDatabase { Task PutAsync<T>(string key, T value, TimeSpan timeOut); Task<T> GetAsync<T>(string key); Task InvalidateAsync(paramsstring[] keys); }