Turning a visual flow tool into a .NET orchestration platform
C# / .NETNode-REDTypeScript / NPM packagesGCP (Pub/Sub, GKE, Firestore)GitLab CI
Internal system and platform names are withheld; this writeup describes the engineering approach in general terms only.
The problem
A unified purchase gateway serving an entire catalogue of consumer websites is a coordination problem. Many services, several languages, teams on two continents, each owning a slice of the purchase lifecycle. Something had to wire them into coherent, observable business workflows.
Act one: a visual flow tool as a saga orchestrator
The first answer was Node-RED, an open-source visual flow tool built for IoT — an unconventional fit that worked. Flows are explicit and reviewable, the editor doubles as living documentation, and the runtime extends through custom node packages.
It was run as a real platform, not a toy: integrations shipped as versioned TypeScript NPM packages of custom nodes, flows were git-backed with full CI/CD, and business logic lived in the flows themselves. I was the main developer of that business-flow logic, and built many of the integration packages teams composed into production workflows.
Act two: a new runtime underneath
Node-RED eventually hit its ceiling for this workload: a Node.js runtime executing payment-critical orchestration at scale, with operational and typing limitations that fought the rest of a .NET-heavy estate.
The move was to keep the editor and rebuild what ran underneath it in .NET — so the part people valued, designing and reviewing flows visually, stayed exactly as it was, while execution moved onto a platform the organization could operate, type and performance-tune properly. It came out markedly faster and considerably cleaner to run.
I contributed to that platform work, remained the main developer of the business flows running on it, and trained engineers in both countries as new teams adopted it.
Why it matters
Flow orchestration is the quiet infrastructure behind everything else here that says “orchestrated through flows”: payment-system integrations, compliance workflows, reconciliation, and the rebilling decision engine.
It is also a case study in platform pragmatism. Forking a beloved open-source tool sounds reckless in a design review and turns out to be the cheap option — because the expensive thing was never the runtime. It was the interaction model people had already built their working habits around. Replace the engine, keep the cockpit.