We’ll delve into the ins and outs of cache hit rates below and how some of our users have a 99%+ overall cache hit rate, but if you’re ready to start caching your GraphQL API, let’s do it!
Have you ever wondered how the makeup of your application affects your cache hit rate? Have you ever dreamed of having the best cache hit rate of all time? We salute you. But pomp without performance gets you nowhere. So, let’s take a look at how cache hit rates compare for different use cases.
Your use case affects your cache hit rate
Simply put, caching is ideal for read-heavy and public use cases. The more write-heavy or private (i.e. specific to a single user) your data, the lower your cache hit rate. You can imagine this like a graph with four quadrants:
Yet, across the thousands of GraphQL APIs we’ve seen, it’s almost never quite that clear cut. Let's take a look at some common examples.
Read-heavy and public: news websites
One example of read-heavy and public data is news websites. One author publishes an article, many many people read that exact article and it changes very rarely (except for a few typo fixes maybe). Patronage, who build 30-40 news websites a year powered by Stellate, see overall cache hit rates of 99%+!
Write-heavy, private use: error tracking
On the other extreme end could be an error-tracking service. Only authenticated users can see the error data and these services ingest, process, and aggregate millions of events of which only a few will ever be viewed once or twice (hopefully!). This would result in an extremely low cache hit rate, which is why I don’t have an example customer here — no error tracking services use the Stellate Edge Cache, and for good reason! They wouldn’t get any value out of it.
In the real world: your GraphQL API is likely a mix!
Yet as we said, in the real world it’s rarely that black and white – most GraphQL APIs include a little bit of both in different queries. For example, an e-commerce store can have read-heavy, public queries as millions of users look at the same products that are available to everyone. Meanwhile, some queries can also be write-heavy and private, such as adding something to your shopping cart — which will always be unique to you and you'll rarely look at it more often than you add items to it.
That's why the Stellate Edge Cache gives you full control over which queries you want to cache and for how long. That means across our networks our customers have pretty high cache hit rates, particularly for their most valuable queries. For example, our customer Italic has a ~60%+ overall cache hit rate (meaning 60% less origin traffic!) and a 98%+ cache hit rate on their product queries – all with the help of our edge caching!