ADR-0009 — S3 object storage for the tile cache and the rasters (COG)

Date: 2026-09-01 · Status: accepted (validated by prototype 4)

Context

In a cluster with ephemeral replicas, the tile cache and the rasters cannot live on the pods' disks; a shared RWX volume is possible but is neither object storage nor cloud-native. The sub-project 5 mosaics will have to read granules on S3.

Decision

1. GeoWebCache tile cache on S3 (gwc-s3 extension), default blobstore, created by the initialization plugin from the s3-credentials Secret; tile layers created by code.
2. Rasters as COG on S3, read by ranges via the cog-core + cog-s3 modules (S3 RangeReader, path-style and endpoint via the IIO_S3_AWS_* variables). Any raster deposited into the platform is a Cloud Optimized GeoTIFF.
3. S3-compatible storage provided by the platform; everything parameterized (endpoint, region, path-style, buckets, keys); SeaweedFS test bench (Apache 2.0).
4. Endpoint pre-check at bootstrap (exit code 5); without an S3 Secret, fallback to a local ephemeral cache.

Measurements

MISS → HIT on one pod, direct HIT on another pod, HIT after pod replacement and after scaling; identical COG GetMap on two pods; wrong endpoint: shutdown in 3 s.

Rejected alternatives

Alternative	Why rejected
RWX PVC for the cache and the rasters	Not object storage, depends on network storage, no CDN possible
s3-geotiff (community)	No ImageMosaic support; COG is the standard
MinIO for the test bench	AGPL license
Blobstore created via REST/UI	Non-persistence experienced (ADR-0006)

Consequences

• The ingestion service (sub-project 5) produces COGs and deposits them on S3.
• Tile retention/expiration policy and seeding remain to be defined (out of scope).
• The raster's unit and parameter travel in the COG metadata (ADR-0003).