Lumir SAR Data Platform
Unified search, storage, analysis, and request for Sentinel + LumirX — an internal satellite-data full-stack service (3 layers)
A user request flows left→right through frontend → data & ops platform (NestJS) → InSAR analysis platform (FastAPI); the InSAR results return to the data & ops platform to answer the user. The data & ops platform (NestJS) fetches InSAR data from the InSAR analysis platform (FastAPI) over an API, then stores and relays it. Solid (amber) = forward request, dashed = response / data feedback. One person owns all three layers full-stack.
There was no integrated service to take Sentinel and LumirX data from search through storage, analysis, and request in one cycle. Storage (NAS + CDSE), InSAR analysis (SNAP · ISCE2 · MintPy), and the user-facing frontend were all separate — making it hard for a user to get from 'I want this location' to a finished result.
I'm solo-designing and building the 3-layer integrated service. Data & Ops Platform (sar-data-retrieval, NestJS monorepo + CDSE + NAS PoC + DDD 5-layer) + InSAR Analysis Platform (lumir-linux-snap, 5-tool stack + multi-agent worktrees) + Frontend layer (sar-search-and-analyzer, Next.js + map + AOI + analysis-request UI). All three are 100% AI-native.
With ISCE2 in place, the InSAR analysis platform is fast enough that weather- and season-independent surface-displacement data as a service is now feasible. The key point: a user picking a location on the map gets either the stored result instantly, or a freshly-processed one — and the whole pipeline is full-stack-owned by a single person.
All three layers, solo (sar-data-retrieval's 5 areas in full · lumir-linux-snap tool selection & operation · sar-search-and-analyzer's frontend in full). The integrated vision is also mine.
Some patterns in each layer came from elsewhere — the Plan/Current environment split (from the team lead) and parts of the SAR domain knowledge (AI as a thinking partner).
Interview Q&A prep
Q.How do the three layers come together as one service?+
Q.How is one person able to run all three layers at once?+
Q.What's your contribution vs. inherited scope in each layer?+
Q.Is any of this exposed externally?+
- ·End-to-end completion date (analysis → data & ops → frontend)
- ·Internal user count
- ·Number of satellites supported (currently Sentinel-1 + LumirX planned)
Each of the 3 layers in detail
Each layer of the integrated box, expanded. These are the deep-link landing points for external search and sharing.
Sentinel SAR search & analysis backend
NestJS monorepo + CDSE + NAS PoC + DDD 5-layer + snap integration (AI native)
We needed a previously-nonexistent platform for weather- and season-independent surface displacement data, plus a unified backend for Sentinel SAR search, download, and metadata. A service layer that exposes snap-processed results in location-searchable form was also missing.
Built a NestJS monorepo (sentinel-retrieval + ai-processing) on top of the CDSE API, ran a NAS PoC (SMB2 vs direct FS), modeled the SLC domain, applied DDD 5-layer, and added an integration layer for the snap separate repo. Done AI-native; the domain structure was only tweaked at the points where predictable boilerplate emerged.
This is the data & ops platform of the 3-layer integrated service — the foundation that lets a user's location query be answered with already-analyzed data instantly, or with newly-processed data on the fly.
Sentinel-1 InSAR processing pipeline
5-tool stack + an InSAR-results API delivered to an external platform · joint-gov surface-displacement monitoring
On the joint-gov surface-displacement monitoring program, a SNAP-only pipeline couldn't keep up with real-time service demands. The LOS 1-D limit of ASC-only SBAS, and the minimum 2-year stack required to identify per-building hotspots, also had to be addressed.
Ran a 5-tool stack (SNAP 12 + SNAPHU 2.0.3 + MintPy 1.6.2 + StaMPS PSI + ISCE2 2.6.3). Anti-over-engineering as the working principle, tool selection done with AI as a thinking partner, and multi-Claude-Code agent worktrees (agents 1–4 in parallel + a gpt_isolated wrapper + handoff system). I consolidated the PSI path around a self-contained coregistration (-W slc) that bypasses ifg/unwrap, then validated it end-to-end on real data (through velocity.h5) by fixing 7 bugs that passed unit tests yet only surfaced in real runs. On top of that I designed the FastAPI operational layer that delivers results to an external 3D platform (/xyz/* time series · /aoi/assess · /baseline/perp), plus preflight endpoints that diagnose suitability in seconds before any heavy run, and owned the ops hardening — auto-start on reboot (Docker) and automatic disk-full eviction to NAS (systemd timer).
Introducing ISCE2 unlocked the processing speed needed to make the InSAR analysis platform of the 3-layer service viable. Outputs: Mt. Sirubong −17.30 mm/yr subsidence (GNSS-verified), 5,143,119 PSI persistent scatterers, 5 m DEM TC, and program reports v1–v4 — all AI-native, with near-zero writing time. Coverage then expanded from Gwanggyo to Jukjeon and Songdo (with a Saemangeum AOI staged); on the Songdo reclaimed land, a production PSI run detected 45,081 persistent scatterers (−17.9 to +16.5 mm/yr subsidence), ingested into the dashboard. I also delivered the external platform's required 'XYZ coordinate time series': re-architecting the full-series bulk response (81 MB · 13 s) into a per-epoch snapshot binary + point-click split brought it to 1.1 MB · 0.56 s — done by first measuring that the DB query was only 73 ms, so the bottleneck was serialization and transfer, then changing the payload structure.
The measured quantity — ground/crustal deformation — is my master's field (crustal deformation · GNSS). The SAR processing tools and pipelines (SNAP, MintPy, StaMPS, …), though, I picked up after joining with AI as a thinking partner — a role expansion. Domain judgment from research; processing implementation accelerated by AI.
Sentinel SAR search & request frontend
Map-driven SAR data search · download · InSAR analysis requests
We needed an internal frontend that lets users search satellite data on a map and request InSAR analysis in one place — the entry point that ties the data & ops platform and the InSAR analysis platform together.
A Next.js (App Router) frontend: a Plan/Current environment-split pattern, a (sar) domain (user/admin pages), and a Next.js Route-Handler BFF. The BFF calls the data & ops platform (sar-data-retrieval) and the InSAR analysis platform, tying search, download, and analysis requests into a single entry point.
Map-based AOI polygons + catalog search + InSAR analysis requests — the user UI is being planned and built right now. The core work is keeping the interfaces with the data & ops platform and the InSAR analysis platform consistent.
Currently runs standalone in Plan (mock) mode, with no backend dependency. The Plan/Current environment-split pattern was inherited from the team lead.