Search Optimization
SkyWatch's EarthCache API lets developers search satellite imagery archives by area, date, and sensor before placing an order. Search fans out to multiple imagery providers on every query. I redesigned the search flow so results stream to the client as each provider responds, instead of waiting for the slowest one, and cut average API latency from 180 ms to 45 ms on the backend path.
By the numbers
- Fastest provider
- Time to first result, instead of waiting on the slowest
- 180ms → 45ms
- Average search API response time on the backend path
- 75%
- Latency reduction after the query path redesign
The problem
Users entered a search area and criteria, and the backend queried multiple imagery providers in parallel. The UI waited until every provider returned before showing anything, then ran pricing and processing on the full result set. Time to first result was effectively the slowest provider plus post-processing, so users often stared at a loading screen even when faster providers had already returned usable imagery.
Approach
I split the pipeline so pricing and processing could run in parallel with provider fetches instead of blocking the first paint. A WebSocket connection streams each provider's results to the client as they arrive, so the UI can render incrementally. We also tuned how providers return results so the streaming model could deliver value immediately rather than waiting for a complete batch.
My contribution
I owned the search flow redesign end to end: decoupling fetch from enrichment, adding real-time delivery, and tightening the underlying API query path.
Decoupled fetch from pricing and processing
Moved pricing and metadata processing off the critical path to first result. Enrichment runs alongside provider fetches instead of gating the UI until every provider and every downstream step finishes.
WebSocket streaming for incremental results
Replaced the all-or-nothing batch response with a WebSocket stream that pushes each provider's results as they arrive. Users see imagery when the fastest provider responds, not when the slowest one finally completes.
Provider return-time tuning
Worked with provider integrations so return behavior fit the streaming model, letting partial results surface early instead of holding everything back for a synchronized release.
Backend query path optimization
Profiled and tightened the PostgreSQL-backed search path behind the REST API. Average response time dropped from 180 ms to 45 ms on the common bounding-box search case.
Next
Days Gone
Reconstruct citizenship travel dates from messy records, with on-device WebLLM parsing when rules fall short.
Learn more →