Building GraphFlow: An Interactive Distributed Systems Simulator in Pure SVG

Hey everyone! 👋

Today I'm excited to open-source GraphFlow, an interactive browser-based distributed systems modeler and chaos simulator.

• ⚡ Live Simulator: graph-flow-virid.vercel.app
• 🔗 GitHub Repository: github.com/Hanubaki/GraphFlow

---

The Problem: Architecture Diagrams Are Inert

Whenever we design distributed microservices, we reach for tools like draw.io, Miro, Lucidchart, or Excalidraw.

While they look great in documentation, static boxes and arrows can't tell you how your system actually behaves. They don't reveal:

• What happens when a downstream worker starts choking?
• How packet latency compounds across synchronous gRPC calls?
• Whether an upstream circuit breaker will trip and isolate failures before crashing your entire API Gateway.

I wanted a tool where the diagram actually runs.

---

What Makes GraphFlow Different?

GraphFlow is not just a diagramming canvas; it's a living, client-side simulation engine:

1. Native SVG Vector Calculus (60 FPS)

Request packets travel along cubic Bézier curves evaluated on every single frame with the De Casteljau algorithm. There are no heavy canvas dependencies or bulky WebGL runtimes — the entire bundle is lightweight (< 75 KB compressed).

2. Live Chaos & DDoS Surge Testing

With a single click on "Inject Surge", you can simulate real-world load spikes (e.g. jumping from 700 to 2,450+ RPS), tune node error rates, and observe cascading HTTP 500 error packets propagating into Dead Letter Queues (DLQ) in real time.

3. Infrastructure as Code (IaC) & Spec Export

Your architecture is never locked into the browser. With one click, export directly to:

• Terraform (IaC) scaffolding
• Docker Compose network definitions
• GitHub-flavored Mermaid Markdown documentation

4. Zero-Cost Instant State Sharing

The entire system topology, node states, and simulation parameters compress directly into a shareable URL hash. You can send a link to your colleagues on Slack, and they will load your exact interactive simulation with zero database friction.

5. Local-First & Offline Ready

Runs 100% in your browser. Even without an AI API key or cloud database, built-in neural rules and local storage keep everything completely functional offline.

---

Tech Stack

• Framework: React + TypeScript + Vite
• Styling: Tailwind CSS (Engineered "Control Room" dark archetype, WCAG AA compliant)
• Math & Animation: Native SVG + requestAnimationFrame cubic Bézier calculus
• State & Testing: Zustand, Vitest (TDD regression test suite)
• License: MIT Open Source

---

I'd Love Your Feedback!

GraphFlow is 100% free and open-source. What distributed patterns or failure modes would you like to see modeled next?

• 🚀 Try it live: graph-flow-virid.vercel.app
• ⭐ Star the project on GitHub: github.com/Hanubaki/GraphFlow

Thanks for reading, and happy designing!

Comments

[Launch Gate]

For the shareable "exact simulation" claim, I'd test a replay boundary: save a topology just before injecting a surge, open its URL in a fresh tab, and run the same fault sequence with a fixed random seed. Compare circuit-breaker transitions and DLQ counts, not just matching node settings. Then background one tab and return after 30 seconds to check whether requestAnimationFrame throttling changes the simulated outcome. Does simulation time advance independently of rendering, and does the link preserve the seed/current state or only the configuration?

[Berke Akdemir]

Spot-on observation, and thanks for asking such a deeply technical question!

To answer directly:

1. What the URL preserves:
   Right now, the URL hash encodes the exact topology configuration (nodes, coordinates, baseline latency profiles, configured error rates, throughput parameters, and edge wire protocols), rather than ephemeral in-flight packets or an active PRNG seed. When opened in a fresh tab, it boots up the identical architecture deterministically in terms of structure, but the runtime packet generation currently relies on stochastic Math.random() sampling rather than a fixed seed.

2. Simulation clock vs. Rendering:
   Simulation advancement is currently coupled to the rendering loop via requestAnimationFrame, with a clamped delta-time tick (dt = Math.min(32, timestamp - lastTimestamp)). When you background the tab, the browser throttles rAF; our delta clamp prevents packets from teleporting across edges upon return, but simulation time effectively pauses/throttles rather than running on an independent headless Web Worker clock.

Your suggestion about a replay boundary with a fixed PRNG seed (e.g., Mulberry32 or xoshiro) in the URL hash and recording circuit-breaker state transitions is brilliant. It would turn GraphFlow from a visual topology modeler into a reproducible incident replay engine.

I’ve just added this to our architectural backlog for v1.2! Really appreciate the feedback.

[DEV SUPPORTS]

You need to verify your account.

tr.ee/dev-to

[Svg/icons]

Using SVG paths for moving packets makes sense here. Does performance hold up as the graph gets bigger?

[Berke Akdemir]

Great question! The short answer is: yes, for typical distributed system topologies (10–50 nodes and hundreds of concurrent packets), it stays solidly at 60 FPS.

Here is how we keep the SVG pipeline performant:

1. Pure Algebraic Evaluation (No Layout Thrashing):
   Many SVG particle implementations rely on the native browser SVGPathElement.getPointAtLength() API every frame, which causes severe DOM layout thrashing and reflows. Instead, GraphFlow evaluates cubic Bézier curves algebraically using De Casteljau’s algorithm directly in JavaScript on requestAnimationFrame. It outputs raw (x, y) floats with zero DOM reads.

2. Decoupled React Reconciliation:
   The 60 FPS packet advancement loop is decoupled from heavy React re-renders. High-frequency particle updates bypass node components, and telemetry metrics (RPS, delivery counts) are committed to React state in 1 Hz throttled batches rather than 60 times per second.

3. Packet Lifecycle Management:
   Packet queues are bounded with active garbage collection upon delivery or TTL expiry, preventing runaway SVG DOM element counts.

Where is the ceiling?
For system design modeling (which rarely exceeds 50–100 microservices on a single architecture review canvas), pure SVG gives us infinite crispness, zero DPI blur, and a sub-75 KB bundle without bloated canvas/WebGL runtimes.

If someone ever models a massive cluster of 500+ nodes with 5,000+ simultaneous in-flight packets, the DOM element limit of SVG would eventually be reached — at which point rendering the particle layer on an overlaid HTML5 <canvas> while keeping nodes as interactive SVG would be the natural evolution.

Thanks for asking!