{"id":517010,"date":"2023-07-12T09:20:46","date_gmt":"2023-07-12T07:20:46","guid":{"rendered":"https:\/\/www.devoteam.com\/expert-view\/using-firestore-as-a-dynamic-cache\/"},"modified":"2025-04-10T10:40:23","modified_gmt":"2025-04-10T08:40:23","slug":"using-firestore-as-a-dynamic-cache","status":"publish","type":"expert-view","link":"https:\/\/devoteam.info\/en-pt\/expert-view\/using-firestore-as-a-dynamic-cache\/","title":{"rendered":"Using Firestore as a Dynamic Cache"},"content":{"rendered":"\n

The Scenario <\/h2>\n\n\n\n

The API serves a user base with hundreds of thousands of users who have a high demand for our services. Receiving up to 8,000 requests per second during peak times. These users are passionate and actively engaged with our content, making it crucial to ensure timely data updates to avoid negative social media feedback. An improved version of the API using Google Cloud was released, serving both old and new data.<\/p>\n\n\n\n

However, an unexpected challenge surfaced. The usage and engagement surpassed our expectations, resulting in a concerning 99th percentile latency of 7 seconds for the data API. Fortunately, the peak usage occurred on weekends, and the dedicated users remained active throughout the week. Although this provided some relief, there was a tight deadline of five days to resolve the issue. In response, we focused on Redis as a potential solution, as it showed promising features to help us overcome these problems.<\/p>\n\n\n\n

The challenge<\/h2>\n\n\n\n

Redis<\/a> was considered a potential solution because of its reputation for quickly delivering document sets in sub-millisecond timeframes. What seemed like the perfect fit for the needs.<\/p>\n\n\n\n

Upon closer examination, it became clear that while Redis excelled in speed, it had certain drawbacks. To put it in perspective, let’s use an analogy. Think of a Bugatti Chiron Supersport, an impressive engineering marvel that can get you from Belgium to Portugal in just 4 hours. Amazing, right? But there are downsides. It can’t accommodate your entire family, you’ll likely accumulate numerous speeding tickets, and it consumes fuel (and money) at an alarming rate.<\/p>\n\n\n\n

Sub-second speeds weren\u2019t needed for the API. Instead, the primary requirements were:<\/p>\n\n\n\n

    \n
  1. The ability to store and retrieve cached data with a 99th percentile latency below 500 milliseconds.<\/li>\n\n\n\n
  2. The capability to scale seamlessly without compromising the first requirement, effectively handling increasing demands.<\/li>\n\n\n\n
  3. Quick invalidation of selected entries, ideally below 5 seconds, without impacting the first two requirements.<\/li>\n<\/ol>\n\n\n\n

    Why Redis wasn\u2019t the right pick<\/h2>\n\n\n\n

    Redis delivers cache data with remarkable speed, meeting the first requirement effectively. Its performance in this aspect is unquestionable. However, the necessary experience to fully comprehend how Redis would handle performance under increased demands wasn\u2019t in place. Although this presented a challenge, it wasn’t an insurmountable obstacle.<\/p>\n\n\n\n

    The real difficulty arose with the third requirement. None of the team members possessed extensive expertise in utilising Redis beyond basic caching functionalities. The advanced querying capabilities weren\u2019t explored or delved into their full potential. While Redis showed promise, it ultimately didn’t align perfectly with the specific needs, given the limited familiarity and experience with its more advanced features.<\/p>\n\n\n\n

    Firestore got our Back<\/h2>\n\n\n\n

    Firestore<\/a> proved to be a great solution for the needs. It met the requirements with reading times below 30 milliseconds and writes below 100 milliseconds. Its querying capabilities were an advantage. The recent addition of Time to Live (TTL) functionality in Firestore was a welcome bonus, further enhancing its appeal. Being a fully managed service by Google, Firestore alleviated any operational concerns. It handled operations and scaling seamlessly, allowing focus on the core tasks.<\/p>\n\n\n\n

    A service developed to streamline the process, standardise requests and check if the data existed in Firestore. If not, it retrieved the data from the source, parsed the response to extract relevant tags, and cached the request using those tags. Intelligent hooks maintained a consistently fresh cache, triggering whenever changes occurred in the original data. These hooks invoked the invalidator, which parsed the changes to extract relevant tags. The invalidator queried Firestore and invalidated the corresponding cached entries using the tags. Not immediately deleting the entries ensured correctness even during periods of high concurrency. Firestore proved to be a capable contender, offering the perfect combination of performance, versatility, and seamless management for the API.<\/p>\n\n\n\n

    Details On The Implementation<\/h2>\n\n\n\n

    The service was implemented in Go<\/a> and deployed on Cloud Run<\/a>. It consisted of two endpoints: the proxy and the invalidator, each deployed in a separate Cloud Run service to ensure smooth operation. One service exclusively handles the proxy, and the other is dedicated to real-time invalidation. This segregation provides a homogenous workflow, simplifying scaling decisions.<\/p>\n\n\n\n

    By leveraging Firestore’s triggers, you establish a seamless connection between data changes and the invoker of the invalidator. Whenever a change occurs in the original data, Firestore triggers the invalidator, initiating our cache invalidation process. This intelligent setup maintains efficiency and prevents interference between the proxy and the invalidation process. The gears are now in motion, and the service is ready to overcome the challenges<\/a>.<\/p>\n\n\n\n

    Results<\/h2>\n\n\n\n
    <\/td>Before Cache<\/strong><\/td>After Cache<\/strong><\/td>Improvements<\/strong><\/td><\/tr>
    Throughput<\/strong><\/td>1675 req\/s<\/td>5993 req\/s<\/td>4318 rec\/s<\/strong><\/td><\/tr>
    Percentile 99<\/strong><\/td>9.96s<\/td>477ms<\/td>9.483s<\/strong><\/td><\/tr>
    Percentile 95<\/strong><\/td>2.52s<\/td>57ms<\/td>2.463s<\/strong><\/td><\/tr>
    Percentile 50<\/strong><\/td>220ms<\/td>22ms<\/td>198ms<\/strong><\/td><\/tr>
    Cache Hits<\/strong><\/td>0%<\/td>*85%<\/td>85%<\/strong><\/td><\/tr>
    Service Instances<\/strong><\/td>606<\/td>**200<\/td>400<\/strong><\/td><\/tr>
    Cache Instances<\/strong><\/td>0<\/td>20<\/td>20<\/strong><\/td><\/tr>
    Invalidator Instances<\/strong><\/td>0<\/td>2<\/td>2<\/strong><\/td><\/tr>
    Total Memory<\/strong><\/td>606 Gb<\/td>203.5 Gb<\/td>402.5 Gb<\/strong><\/td><\/tr><\/tbody><\/table>
    * This number should be higher, but there is one endpoint that does not respect the REST API best practices resulting in being unable to be cached. Because it does not mess with the SLAs, this issue was never addressed.
    ** The main server is fundamentally heavy. Without restructuring we cannot lower more than this.<\/figcaption><\/figure>\n\n\n\n

    During peak weekend usage, caching was important in improving the system’s capabilities. Most cache invalidations occur within a second, with occasional instances exceeding 5 seconds. These longer durations typically arise when streaming and invalidating a large number of documents simultaneously.<\/p>\n\n\n\n

    From a cost perspective, caching has been a game-changer. Previously, the service required reading an average of 6 documents for single-resource endpoints and approximately 150 documents for multiple-resource endpoints. With cached hits, a single read is all it takes. Resulting in significant cost reduction while maintaining efficient operations.<\/p>\n\n\n\n

    Conclusion<\/h2>\n\n\n\n

    Firestore is a versatile caching solution for REST services or websites. It offers scalability, flexibility, and performance that meets most Service Level Objectives (SLOs). As a fully managed service, it handles all the management tasks, allowing you to focus on your core business. With Firestore, you only pay for the resources you use, ensuring cost-effectiveness.<\/p>\n\n\n\n

    Whether you want to optimise your caching, gain more flexibility, or prefer a managed cache experience, Firestore empowers your caching efforts. It unlocks the full potential of your applications and websites with its powerful capabilities.<\/p>\n\n\n\n

    Looking for a managed cache solution, more flexibility and ready to pay only for the resources you utilise? Contact us now<\/a> to explore the possibilities.<\/p>\n\n\n\n

    Future Applications<\/h2>\n\n\n\n

    Enhance your server infrastructure with upcoming advancements that deliver remarkable performance improvements:<\/p>\n\n\n\n