Cache is not only about speed; it's also about saving money. This is how I went from a $10,065 monthly bill to $587. Most people think about caching when the system gets slow. But there are many opportunities to save also money using cache. Here is an example: We consume an external service for client verifications (Know your business). The service charges us per request; every time we search for a record, we get a little ding in our bank account. It wasn't a problem at the beginning; we had a few hundred customers, and a few cents didn't make any difference. But as our system grew on demand (a good problem to have), those cents became dollars. Once we hit the 10K mark, I knew it was time for refactoring. How I solved the problem? 1. I looked at the usage pattern I went back to the traces; the idea was to establish a usage pattern, and I found it. The approval process takes 5 steps. And in each of those, the system asks for the same info from the external service. The approval often takes between 1 - 10 days. (This is important; here you have your expiration window) 2. I understood what to cache The Response to the external service was huge and returned much info we sincerely didn't need. I created a light version with the info we need and, actually, a better structure for our consumers. 3. I defined the key This was a bit tricky since we can't use the Business ID as a key (it is confidential). So, I created a hashed mechanism to obfuscate it. Now for the fun part. 4. I implemented the cache logic Before requesting the external service, check if the data is already in your cache using the cache key. If the data is in the cache, serve it directly, bypassing the external request. If the data is not in the cache, call the external service, then store the result in your cache for future requests. We also provide a mechanism to force the cache eviction if the consumer wants to. From there, we deployed the solution, and it was time for bragging (just a little) ... and monitoring. 😉

Data structure and Algorithm questions are one of the most complex you can have in an interview. The good news is that you can estimate the order of many basic algorithms using common sense. These are the 6 rules I use. 1 of 7