Scalable hosted feature layers in ArcGIS Online: Tile queries and response caching

This article was originally published on December 12, 2017, and has been updated. 

Hosted feature layers come in all shapes and sizes; some start off big, some grow over time as data is updated. Regardless of their origins, it’s important that datasets remain performant, which brings me to the topic of this article: response caching. Response caching might sound a bit boring on the surface but I think it’s pretty exciting as it allows hosted feature layers to scale even when your maps go viral.

Before I dive in, though, let’s talk about what a response is.  A response is simply the feature layer’s answer to a question you asked it.  While you can ask many questions, the most common one that is asked is: What features are in the map I’m looking at?

Response caching explained

ArcGIS API for Javascript clients, and by extension ArcGIS Online, work well with layers of all sizes.  When feature layers have a small number of features, they can be retrieved in a single request because the response from the feature layer is small. For larger layers, features are requested using tile requests (splitting the query up into several smaller spatial queries). Tile requests have the added benefit of being consistent, even across different users and apps.  This consistency allows the responses to be cached once on the server and shared between all users. In both cases (single or tile), the requests can also be cached on the client.

Because ArcGIS Online uses server-side response caching when multiple users request the same information, that cache kicks in.  This frees up the resources on both the server and the underlying database, allowing feature layers to scale out to millions of users and clients without the need to explicitly generate tiles ahead of time (which ArcGIS Online also supports when you need it).  These cached responses from the server are automatically invalidated as the data is edited.  This ensures that clients using the layer always get the latest information.

For many of you, the simple story is: “ArcGIS Online uses tile queries and response caching strategically to optimize performance and reduce load.”  For some of you, knowing that is enough.  But for the more curious geogeeks, the rest of this article provides a deeper dive under the hood to help you understand all the moving parts that work in harmony to deliver performant feature layers in ArcGIS Online.

Client-side caching: Your personal cache in your browser

Client-side caching is like your own personal cache of responses from the server, managed by your web browser.  When you query a feature layer, the feature layer responds with a set of features that is downloaded and stored in your browser’s cache.  As you pan around the map, or zoom in and out, the browser uses the downloaded features in the browser cache whenever possible to avoid having to re-download the features every time the map view changes.

The browser cache has a shelf life, though. If you pan around your data while it is being edited, the browser asks the servers whether anything has changed since the last time it queried. If so, the browser gets the new features and updates its cache accordingly.  This ensures that what you’re seeing on the map is current, and reduces the load on your computer and ArcGIS Online. The browser cache only persists on the client and is not stored anywhere else. Therefor, this only benefits you and won’t make anyone else’s experience faster.   That brings us to the content delivery network (CDN).  Its goal is to improve the experience for everyone.

CDN: A cache for everyone, anywhere

Content delivery networks, or CDN for short, are the backbone of a speedy internet.  For publicly shared hosted feature layers, the CDN acts similarly to client-side caching but with a couple of key differences. First, the CDN response cache is reused by anyone using the layer and sending the same query, so everyone benefits from it, not just you.  Second, the CDN is distributed all over the world, and the cache is mirrored, which means even if the servers hosting the data are halfway around the world, the cache is most likely much closer to you. So, in addition to being cached, the data has fewer hops over the internet to reach you, making it faster for the browser to download to its cache.

Server-side caching: Shared and stored in ArcGIS Online

As mentioned in the previous section of this post, only publicly shared layers use the CDN, so layers shared within your organization do not use the CDN response cache. This ensures that your private data is not cached on external servers around the world.  Server-side caching caches the responses to tile requests within ArcGIS Online so that other users in your organization and the public can reuse the cache when the browser cache and the CDN can’t be used.  This is called the feature tile cache, and it is shared between all authorized users and maintained internally as part of the ArcGIS Online infrastructure.  As a result, queries come back quickly, load to the underlying databases is reduced, and everything runs smoothly at scale, even under heavy load.  As your data changes, the feature tile cache is invalidated to ensure that clients using the feature layer always see the most current information.

Wrap-up: Response caching in a nutshell

When you put all the caching methods together for hosted feature layers, the workflow looks something like this:

Learn more

This is the third article in a 3-part series about ArcGIS Online data management best practices to support scalable public-facing web apps and apps. If you missed the first two articles in the series, Tracking your ArcGIS Online Feature Data Store Key Health Indicators and Essential Configurations for Scalable ArcGIS Online Web Applications, please check them out for more essential data management tips.