Repository navigation
Possible caching strategies for eoAPI TiTiler tiles #381
Description
- We need to serve new tiles for every single request.
- Perhaps we should implement some sort of caching.
- A problem is that the nginx ingress provider will be deprecated soonish, so we need to migrate to something using the k8s Gateway API.
- Let's consider good lightweight options that would save us money, and improve user experience.
Not sure if this falls under the eoAPI upgrades / improvements. If yes, great! If no, any suggestions so we can look into it? (perhaps you have done this before on big eoAPI deployments?)
Reacted by Kshitij
Activity
linear commentedon Nov 4, 2026
TECH-1398
pantierra commentedon Nov 6, 2026
Right now every tile is rendered on request. I timed an item tile at about 3.5s cold and 1s on a repeat, and the repeat is only faster because of GDAL's cache inside the pod, so every new user or pod pays the full cost again. TiTiler already sends
Cache-Control: public, max-age=3600, but nothing shared sits in front to use it. global-tms caches its own tiles up to z13, but from z14 it redirects to/raster/searches/..., which isn't cached either.The simplest fix is to put CloudFront in front of
api.imagery.hotosm.organd cache only the/raster/*tile paths, letting STAC and uploads pass through as they do today. Users far from us-east would get tiles from a nearby edge, TiTiler would need fewer pods (it currently scales between 2 and 12), and traffic from AWS to CloudFront is free. HOT already uses CloudFront for the fAIr and Drone-TM frontends, so it isn't new to the account.How long to cache depends on the tile. Item tiles (
/collections/{c}/items/{id}/tiles/...) only change when an item is removed, so they can be cached for a week or more and invalidated on takedown. Mosaic tiles (/searches/...) change as new imagery comes in, so they chould stay at about an hour.If a CDN isn't an option, a small nginx or Varnish cache in the cluster in front of TiTiler would also work. It's simpler on the AWS side, but it only caches in one region and uses cluster resources.
Either way, this doesn't depend on ingress-nginx. CloudFront talks to the load balancer, whatever runs behind it, and caching in the ingress itself would mean building on a component that has been retired since March 2026. Moving the cluster to the Gateway API is still needed, but that's a separate job, and caching doesn't have to wait for it.