The OMDB service will help motivate us to think about caching and what it can do for us.
Go to OMDB try it out in its native form. Look up some movies and actors and get a feel for what this web service does.
Now lets go see this service ‘wrapped up’ in our example application.
This last call is where we go to the OMDB web service and pull data down.
Review the latency and number of calls figures, shown just under the movie:
You’ll see that we’ve got a couple of issues here:
This latency (625ms in the image above) is unacceptable. Clicking the button a few more times brings it down to under 100ms (your numbers might be very different). However one only has a total of around 500 ms from the time users click on the interface to get the response back before they start dropping off, according to research by Google. Giving up ⅕ of your time budget at the very first step is expensive and unnecessary!
Furthermore, each and every time a user looks at this data that action depletes a limited resource: the number of calls to the OMDB service permitted in this 24 hour period. (You can see the number used steadily increasing each time you click the green arrow!)
Redis is a perfect solution here. By enabling caching one can: