Lumir SAR Data Platform
Unified search, storage, analysis, and request for Sentinel + LumirX — an internal satellite-data full-stack service (3 layers)
A user's location request flows down the frontend → storage → analysis spine and returns as a result. The center axis (amber) is the forward request, the right side is response / write-back, the left side is the external data feeds. 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. **Storage layer** (sar-data-retrieval, NestJS monorepo + CDSE + NAS PoC + DDD 5-layer) + **Analysis layer** (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, and I'm back-transferring the 4-layer + CQRS + Korean-method-name pattern validated in him into the company backend design.
With ISCE2 in place, the analysis layer 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 apps/web in full + the backend design doc). 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). The sar-search-and-analyzer backend (apps/api · worker · crawler) is still at the CLAUDE.md design-document stage; actual implementation belongs to the next phase.
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 → storage → 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 sister repo. Done AI-native; the domain structure was only tweaked at the points where predictable boilerplate emerged.
This is the storage layer 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). 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 analysis layer 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. 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.
SAR is outside my primary role (web development). I'd consider entering it impossible without AI as a thinking partner — a textbook example of stage-3 role expansion.
Sentinel SAR search & request frontend (full-stack-ready)
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 storage and analysis layers together.
Next.js (App Router) + a Plan/Current environment-split pattern + a (sar) domain with user and admin pages + a Next.js Route-Handler BFF. Currently apps/web only; the monorepo (pnpm + libs/*) is pre-staged for future backend additions (apps/api · worker · crawler). I wrote the CLAUDE.md backend design (4-layer Clean Architecture + CQRS + Korean method names) myself, importing the patterns validated in him.
Map-based AOI polygons + catalog search + InSAR analysis requests — the user UI is being planned and built right now. With backend dev and planning happening in parallel, the interface design that keeps both sides aligned is the core work.
Right now there's only apps/web; apps/api · worker · crawler aren't implemented yet. The monorepo is pre-staged for future backend work, and the 4-layer backend is still at the CLAUDE.md design stage. With UI planning and backend design running in parallel, keeping the interface consistent is the priority of this moment.