Top Redis Caching Strategies Every Backend Developer Should Know

have you noticed how apps like Instagram load your feed instantly even with millions of users online the secret lies in caching and when it comes to realtime performance redis is the superhero behind the scenes in this video I'll break down the smartest caching strategies that you can use with redis to make your APS blazingly fast and insanely efficient hey everyone this is VI bataa if you're building APS and want to level up their performance understanding caching

is not optional it's completely essential and Rus with its inmemory speed and Rich data structures gives you the perfect toolbox we'll walk through the most powerful caching strategies when to use them pros and cons for each strategy all with easy to understand diagrams let's get started first off we got cash asset strategy also known as lazy loading this is the most commonly used pattern this is how it works once the read request comes to Service First

Service checks whether the data is stored in redis if data stored in redish it's a cash so basically just simply Returns the data all the way from redish to the client simple okay if at all if the data is not present in redus then first service will try to read the data from the database okay this is Cash Miss right so once the service receives the data from the database it will update into the radius as

well as a cash right so for the subsequent request for the same data the service can retrieve the data from redis directly instead of reading from the database simple one simple example for this strategy cach as said is e-commerce product details when a user views a product page on an online store first API checks whether data is stored in redis if it's missing it pulls data from the database and stores in redis so that it will

be helpful for future request for the same product info so why this example fits for cash aside strategy product data doesn't change often right and also not every product is wied so often so cash is used only when needed so in this whole cash asset strategy the most frequently Red Data is always stored in redish moving to advantages of this strategy simple and widely used only caches data that's actually requested this is very important which we

will correlate with the other strategies later easy to implement and reason about fine grain control over caching logic and there are some disadvantages also with this strategy those are first request is slow cold start because for the very first time that specific product info won't be there in red right so the data will be pulled from database then stored in radi so that it will helpful for next request so always for the very first time that

specific request will be relatively slow because it actually reach from the database so that is called cold start stale data risk if DB is updated and cash is not invalidated again of course we need to do explicit in invalidations but again that's kind of an overhead that comes to the third Point does request manual cash invalidation logic and now you can easily say that this specific strategy is not ideal for WR heavy workloads I hope this

cashes strategy is clear this is the most frequently and widely used you might have already noticed this or implemented in your projects moving on to the next strategy that is write through cach in this strategy instead of reading first it purely focuses on write operation first so when you update or create your data you write to radi and database at the same time so if you look at the diagram over here so for all the write

request this API backend service let's say will basically first write to database and also wres to redu or Vis soura but overall this can be treated as one unit of operation one unit of work in simple terms right so for any WR request either it's a create or update service will make sure that the data is written to both database and also to redish so that's how the representation over here so in the service both writing

to database and also to the cache is treated as one unit of work or maybe as a series of requests simple okay so with this strategy it keeps your data always in sync between radius and database but as you can clearly see this will definitely add a latency because we need to write to the radius also as an extra operation it's a good fit when read speed matters but you still want consistency examples for this can

be like user profile updates in social media apps let's say when the user updates their profile like name bio profile picture or any post let's say the service writes the data to both Rus and database at the same time this way the updated profile information is always fetch from rce and it is always latest and consistent with database so why this specific example fits this specific strategy right through cash profile read as you can see those

are more frequent operations and this needs strong consistency between DB and cash moving on to the advantages of write through cash strategy as you can see cash and database are always in sync read operations are always fast because it always will be a cash sheit and the data will be sent directly from redish now of course as we have this advantages there are disadvantages as well slower rights as we mentioned earlier because we need to make

sure that the data has written to database and also to redish so writing to redis can be like an extra operation that we need to do as part of the actual WR API request so with this case again we can filter it out which type of data so let's say for Instagram we can't store all the millions of users information in red it doesn't make sense so we can use this strategy only for very high popular

social media profiles for the rest of the stuff it can be we can do as a cash aside or something like that so we can streamline this based on the business domain and all so overall there is a high chance that the data will be returned to reduce unnecessarily but again we can filter this out to some extent by selecting that okay we can store this for more high volume user profiles only something like that but

still this can be treated as a disadvantage because we will always store the data in Rus as well and third point I can think of a disadvantage is increased write complexity and resource usage that's pretty much for the write through cach I hope you understood moving on to the next one that is write behind cache now this right behind cach strategy is a bold one reason you write to redus and red takes care of updating that

to database I know it's scary to hear for the very first time but this can also be used in one of the examples I'll just share in a moment and this specific strategy actually is supported by radus Enterprise Solutions where there's a module called radius gears where it will take care of writing the updates to the database in this case as you can see for the write request from the client the service will just write the

data to redis redis have this redis gears module where it will take care of writing the updates to the database so it's can be treated as an asynchronous database rights it can be scheduled or a crown job anything but overall as you can see when compared to the other one over here it will write to both right write through cache it write to both database and cash right so with this case the WR operations will be

way faster because we are just updating because we are just writing to redus and redus will take care of later to write that to the database and that all you can configure with the help of radius gears module so overall it's Ultra fast for wres but you have to be okay with some delays in persistence because it will take a while to update in the database as well also if RIS crashes before flushing the data to

the database you could lose some information unless you enable end off file or rdb persist in redis so one example I can think of for right behind cash strategy is analytics even tracking analytics service example tracking page views or user clicks wres events to radius for fast inje and radius batches rights to the database in the background so in this case it's kind of synchronous right to the radius but asynchronous where radius will take care of

basically updating that into the database so why this specific example fits in this right behind cash strategy so if you see this is like a very high volume right heavy use case because tracking pages and user clicks like you'll get a huge amount of data because in this specific case delayed persistence in database is acceptable and also great for reducing dbo because the amount of data which uh which gets for this specific use case like tracking

Pages or user clicks that will be like a very heavy volume of data right so instead of actually doing that all in a database directly which is doesn't make sense right so we can basically flush it to radius and radius will take care of it as a batch to update bulk updates into the data direct so of course this strategy also will have pros and cons starting with Pros extremely fast WR performance as you can see

there is no database here we always try to reduce so overall comparatively writing to database it will be like extremely fast for heavy volume of course reduces DBL load by batching wres in a way that RIS will take care of writing the right data in batches instead of each individual data point this is ideal for high right throughput systems moving on to cons or disadvantages risk of data loss and redus crash is high unless again Rus

persistence is enabled we need to do complex error handling and Recovery logic next one is delayed consistency DB lacks behind red but for the specific use case that should be okay but I still want to highlight this as a con to some extent and the last disadvantage could be we should make sure redis is durable like end off file setups snapshots replications Etc all right I hope till this point it's clear by the way I have

created build your own red series it's kind of an old close to one year but but I would highly recommend to watch if you want to see how Rish internals works again I have written that in JavaScript but it will basically helps you to understand how an inmemory database can work and they also cover some data structures as well so it's a good watch if you want to check out please go through the playlist as well

all right moving on to the last strategy that is read through cache this one is similar to cash as side but the magic happens purely behind the scenes in the read through cash the service never talks to the database directly so what exactly the case so when you get the read request service will try to get the data from redis internally if redis don't find the data it will try to F the data from the database

and return that as a cast response simple and of course this will you can clearly see there are pros and cons I will cover in a moment so in short radus handles cash misses internally and fetches from the data using a loader it is more abstracted and great if you want to make a centralized cash logic one example for this specific strategy I can think of is scms like system uses read through cach to serve article

content when a reader visits a new article R automatically loads it from DB if it's not cached why this specific example fits because it's seamless integration ensures that the reads always go through radius and minimizing latency again we still need to consider this read up from the database but it's all part of the redish so relatively it will be better when compared to the cash said so advantages of the strategy transparent at the application layer consistent

cash loading mechanism reduces duplicate logic across different services now on to the disadvantages tightly coupled to the cash layer with DB access logic and this strategy is definitely complex to implement we need a cash provider or a library for this kind of less flexibility in cash invalidation scenarios that's all on the four different R strategies that we can use now I just want to extend this to some more interesting topics like TTL invalidation and expiry keeping

your cash always latest and clean should be the primary goal of cash system setting up a proper TTL or time to live is very crucial R makes this very easy by buil-in expiry mechanisms for example you might cash real time metrix for 10 seconds only but product details for an hour or so so with this TTL we'll ensure that we don't serve outdated data based on the different business entities as an example a live sports API

or stock trading app caches scores or prices with a TTL of 10 seconds ensuring users always get the upto-date data without hammering the database as this data changes rapidly so we can use tail with less time and this tail data must expire quickly so by having this TTL invalidation or expiry Logics so we can prevent stale or outdated data automatically and it's very easy to implement with tradus inbuilt expiry and also controls memory usage efficiently and

there are some slight disadvantages again this VAR is based on the business case risk of cash misses will be high if TTL is short and second point is kind of a difficult to choose the right TTL value for the dynamic data it keeps varying and there's one prominent issue that we can see more often that is sudden expiry of many keys in red which will directly impact database for high read through put at a time which

can cause a spike in DB load which also termed as cash stamp a all of these strategies shine in realtime apis think leaderboards product search sis management rate limiting and even live trading dashboards and as an INE some best practices always set ttls irrespective of all the cash strategies yes there are some uh challenges but you can still make sure that ts are set in place based on the different domain entities with t with different TL

values use radi hashes to group related data so it's easy to operate and always some rule monitor your cashit ratios that is very important otherwise you just Implement and you don't know how much that is actually affecting in a good note or in a bad note and last one don't forget to Benchmark these strategies after you implement caching is not just about speed it's about how you craft it redis gives you the tools and now you

know the strategies if you learn something new hit that like button and subscribe for more interesting videos and drop a comment if you want me to do a demo on one of the strategies thank you so much for watching and I'll see you in the next one