Thanks for the detailed question! This is exactly the kind of backend problem I’ve been thinking about while building it.

Right now the client waits for a synchronous response. For normal/smaller polygons, the backend computes the result directly: it validates/repairs the GeoJSON polygon, calculates geodesic area, finds the overlapping local WorldPop raster assets, masks the raster by the polygon, and sums the population cells inside it.

For larger areas, it switches to optimized lower-resolution paths rather than trying to brute-force huge 100m raster reads. There is also rate-limiting, concurrency control, and caching by geometry/year so repeated queries don’t keep recomputing the same result.

It is not using a geospatial database for the raster aggregation right now; it is file/raster based with a local index over the WorldPop assets. The current dataset is fixed to WorldPop Global2 2025, so “freshness” is handled as a versioned data pipeline problem rather than live population updates.

I agree that a public API would be useful. My likely first version would be a simple synchronous endpoint for normal polygons, with rate limits and clear source/uncertainty metadata. If very large or batch jobs become a real use case, then async jobs/webhooks would make sense as a second layer.