Data Flow Visualizer

A data flow visualizer maps processing steps as nodes and dependencies as directed edges. Unlike a static slide, the canvas here is live: you can add a missing middle tier, split a monolithic step, or show an alternate path without redrawing from scratch. The inspector lets each step carry labels and structured metadata—owner, SLA, technology, or links—so the diagram doubles as lightweight documentation.

Two input modes cover different workflows. Arrow text is fastest when you already think in linear or chained stages: separate steps with arrows (Unicode →, ASCII ->, or =>). JSON mode fits checked-in definitions, generated specs, or round-trips from the export button, including node positions when you want to preserve a layout you spent time tuning.

Choose Arrow text or JSON, enter your definition, and click Apply to canvas. Use Add step to drop new nodes, drag from the cyan handles to connect outputs to inputs, and select a node to edit its label or metadata in the inspector. Re-layout runs an automatic layered arrangement (left-to-right or top-to-bottom) over the current graph. Export JSON includes ids, labels, optional metadata, and coordinates; Export PNG captures the viewport for slides or wikis.

Delete removes the selected step and its attached edges; you can also press Delete or Backspace when focus is not inside a text field. Cycle detection uses strongly connected components: any step on a directed loop is flagged in rose. Bottleneck highlighting calls out steps with unusually high total degree or cycle membership, which often merit extra monitoring or capacity planning.

Name steps after responsibilities (Ingest validation) rather than only technology (Lambda) unless the tech choice is the point. Keep one primary direction of data flow so readers can scan the diagram once; use branches sparingly and label them in metadata. When you export JSON, store it next to runbooks or RFCs so diagrams stay versioned with code.

If you see a cycle, decide whether it represents intentional feedback (retries, state machines) or an accidental dependency that should be broken with a queue or event. Hubs are not always bad—API gateways and databases are naturally central—but they warrant explicit capacity and failure-mode notes in metadata.