Please note: Kentico Cloud Deliver service serves content off a CDN network with latencies measured in milliseconds. As we do the performance optimizations through the CDN network, the performance benefit of caching would be rather minimal.
The CDN network is here to geographically replicate the Kentico Cloud content to each region so that it is always served off the closest datacenter. The content can be reached with one single URL (e.g. https://deliver.kenticocloud.com/project_id/items) but it always comes from the closest datacenter.
But, a caching solution could also help in another way. You might be interested in lowering the number of requests coming to the Kentico Cloud Deliver service.
If the data was kept in the cache of the application server for some time, then most of the requests could get served without consuming the CDN requests.
The following diagram demonstrates two facts:
- The latency of the request to Deliver is low as the closest physical CDN endpoint is selected
- The app does not necessarily have to query Deliver and it can serve to client computers using its own cache
The question is, would this be useful to you? Could this be used as is, or should it be improved?
You could improve such configuration by also implementing the geo-replication on the app server (service) level.
For example, Azure has its Traffic Manager offering. It can be configured to redirect client requests to an instance of an Azure App Service app that's closest to the client.
The good news is that Kentico Cloud content can still be accessed with geo-agnostic URLs. You don't have to worry about whether you need to get the US, EU or APAC copy of the content.
However, the downside is that each app instance holds duplicate copies of the same data. If a cache invalidation mechanism is in play, then all the servers need to check for invalid cache data separately.
So, there's a lot of questions to discuss:
- Which reasons lead you to using/not using caching?
- Are you planning on implementing geo-replicated .NET apps?
- Would you prefer a fixed invalidation period (timeout)? Alternatively, would you require a signaling mechanism in Deliver that would announce cache item invalidations?
- How would you deal with cache item dependencies (mainly in regards to modular content)? Would you configure dependencies on the app server side exclusively? Or, would you like Deliver to be able to announce changes in the structure of the modular content?
Feel free to discuss the topic here! We'd love to hear if this is what you'd use in your projects. Then, we could write an article and discuss how we can improve the Deliver .NET SDK, together with the community.