Back to projects
sdpe
Stage 3+4 blend

SDPE — SAR processing pipeline orchestration

Lumir LumirX multi-stage SAR pipeline · NestJS with 5 subsystems + DAG

Processing levels
L0 → L3
Interface chain
CSC 0–9
GitLab CI/CD
From scratch
NestJS subsystems
0
Architecture · data flow
Architecture · data flow
Forward requestControl · pgmqResponse · write-backExternal system

From the console (a React Flow canvas) an operator composes and deploys a processing DAG; the Pipeline Workflow subsystem's orchestrator (CSC-08) acts as a control tower, assigning per-stage jobs over pgmq (SI-04) and tracking completion (SI-03) to advance L0→L3. The DAG itself does not listen to events — it only defines deployment rules ('which condition → which pipeline'; a pipeline is data, not code). Nine CSCs map onto collection (DCS), signal processing (SPS), post-processing (PPS) and service (DSS); files stay on NAS while queues carry only paths/metadata. Products are registered into a PostGIS STAC catalog and the Data Service (CSC-09) serves them over REST·OGC·STAC. A new satellite is added by registering a DAG + profile (near-zero code change). Teal = control (pgmq) / amber = data.

Screens · artifacts
Recorded with Playwright e2e — auto-tour through five console screens in Plan mode (mock data). Satellite-modal bypass → Deployed rules → Data Catalog → Jobs → DAG Console.GIF
Problem

There was no system letting an operator configure, run, trace, and recover the L0–L3 LumirX raw-SAR pipeline, and adding new satellites or algorithms needed to cost as little code change as possible. From my side, I was dropped into the pipeline domain blank-slate.

System

On top of an inherited NestJS 5-subsystem monorepo, I designed and built the DAG planning UI (no Figma — the UI code plus Playwright e2e is the planning document). Built the GitLab CI/CD from zero, did the detailed design for interfaces/csc-8, fed the 80–100-page ICD/SAD docx directly into AI, ran a tight loop of small 'does this break the rule?' reviews, and wired up an auto-redeploy hook that fires when ops-console work completes.

Impact

Despite entering blank-slate, I produced detailed design and implementation on top of my senior's base. The architecture has settled into a shape where adding Sentinel support or a Snappy-based DAG step takes near-zero time.

My contribution

Designed and built the DAG-pipeline planning UI; built the GitLab CI/CD from zero; produced the detailed design for interfaces/csc-8 (csc-7/9 to follow).

Inherited scope

Apps folder structure + natives/csc03 · csc04 + pgmq + ICD/SAD (base design finished by my senior).

Honesty note (for interviews)

pgmq and the tech-stack decisions came from the inherited base design. I read the ICD/SAD myself and extracted the detailed design from them. My senior only dropped hints — but the base design was solid enough that the work went smoothly, which I should acknowledge too.

Interview Q&A prep

Q.How do you separate what you did from what you inherited?+
A.Inherited: apps structure · natives/csc03 · csc04 · pgmq · ICD · SAD. Mine: DAG UI planning · GitLab CI/CD · interfaces/csc-8 detail.
Q.How did you learn the domain knowledge?+
A.AI-first, in parallel with DAG UI design. Whatever I didn't know I asked AI to diagram or visualize; I fed the ICD/SAD docx in directly and ran repeated 'small-violation' reviews.
Q.How is extensibility guaranteed?+
A.A 3-step structure: planning → DAG mapping → processing profile. A new satellite or algorithm costs almost no code change.
Keywords
NestJS · 5 subsystemsDAG pipelinepgmqGitLab CI/CDICD/SAD consistency mechanismNext.js auto-redeploy