Exercise 3: Why Caching Doesn't Fully Eliminate the Rate-Limit Risk — Possible Solution
====================================================================

WHY CACHING HELPS
------------------------------
A recipeCache collection, keyed by ingredient name the same way barcodeCache is keyed by barcode, means that once any user has searched for a given ingredient (like "chicken" or "eggs"), every subsequent search for that same ingredient - by that user or any other user - can be served from the cache instead of hitting TheMealDB again. This genuinely reduces how often the external API actually gets called for common, frequently-repeated ingredients.

WHY IT DOESN'T FULLY ELIMINATE THE RISK
------------------------------
Caching only helps for ingredients that repeat across searches. Every user's pantry will still contain at least some genuinely different or less common ingredients that haven't been searched before, and those still require a fresh call to TheMealDB regardless of how well-populated the cache already is. As the number of users and the variety of ingredients they track grows, the absolute number of first-time, uncached ingredient lookups grows too - caching reduces the load but doesn't put a ceiling on it, since new never-before-seen ingredients keep appearing.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that caching only benefits repeated, already-seen ingredients, and correctly identifies that genuinely new or uncommon ingredients still require fresh API calls regardless of cache size, which is why growth in users and ingredient variety can still increase real load on TheMealDB even with caching in place.