Design a Satellite Imagery Analytics Workflow

Problem statement

Design a satellite imagery analytics workflow that ingests raw satellite scenes, stores them in a tile-based approach, runs batch or streaming classification (for example detecting deforestation), and produces analytics, visualizations, and alerts for anomalies such as illegal logging. The platform must accept tens of terabytes of new imagery per day, normalize it into a queryable catalog, serve tiles to analysts and APIs at interactive latency, run ML classification per tile, stack time series for change detection, and push reviewed alerts to downstream consumers.

This is not a generic ETL problem. Satellite imagery is distinctive in five ways. First, the raw inputs are enormous multi-band raster files: a single commercial scene can be several gigabytes with 8 to 30 spectral bands, and a Sentinel-2 granule is roughly 700 to 800 MB. Second, every pixel has a location, so the primary access pattern is spatial and temporal range queries, not key lookups. Third, the workload is dominated by bulk scans and embarrassingly parallel per-tile compute rather than transactions. Fourth, quality is physical: clouds, haze, sensor noise, and geometric misregistration are first-class data problems, not edge cases. Fifth, the output is often evidence: a deforestation alert may feed enforcement, insurance, or ESG reporting, so provenance and reproducibility matter as much as latency.

Why naive designs fail

A standard answer treats scenes as files in a queue, runs one job per file, and writes results to a database. That design collapses at three points. Ingestion stalls because a monolithic worker cannot decompose a 6 GB strip into parallelizable units. Query dies because scanning billions of files to answer a bounding-box query is unbounded. Analytics drifts because change detection over misaligned time series produces false alerts every time a cloud passes over.

The correct architecture separates four planes. An ingestion plane receives, validates, orthorectifies, and re-encodes scenes into cloud-optimized formats and tiles. A catalog plane indexes every scene and tile by space and time using a SpatioTemporal Asset Catalog model. A compute plane fans out ML classification and change detection across tiles using elastic CPU/GPU pools. An analytics and delivery plane aggregates results into mosaics, dashboards, alert streams, and APIs.

Public operating baseline

The category is operationally real. Planet operates a constellation of over 200 satellites and images the entire Earth landmass daily with its Dove fleet, publishing analysis-ready data at 3 to 5 meter resolution. ESA's Copernicus Sentinel-2 mission, with two satellites, provides 10-meter multispectral coverage with a five-day revisit at the equator, and the Copernicus Data Space hosts well over 100 petabytes of open archive. Google Earth Engine publicly states its catalog exceeds 100 petabytes across more than 1,000 datasets. Brazil's INPE runs DETER, a near-real-time deforestation alert system for the Amazon. These are cited public facts that anchor the domain; every scale number used later for capacity math in this answer is an explicit design assumption unless tied to one of these figures.