DEV Community: Arun

I needed graph traversal queries and ended up building a full incident response tool

Arun — Fri, 26 Jun 2026 11:41:13 +0000

Started this for the H0 Hackathon. The requirement was straightforward, use Vercel with one of three AWS Databases and build something real. I picked Aurora PostgreSQL and ended up going deeper than I expected.

The idea came from a real frustration. Every time something breaks in a microservices setup, the first question is always "what else is affected?" and nobody has a good answer right away. Your monitoring tool tells you service X is down. Cool. But which of the 30 services that depend on X are also broken? How much revenue is at risk? Where do you even start fixing?

That's what Faultline does. You model your service dependencies in a PostgreSQL database, and when a failure happens, it traverses the graph to compute the blast radius. Every affected service, at every depth level, with revenue impact calculated in real time.

Why Aurora PostgreSQL specifically

The blast radius computation is basically a graph problem. The dependencies table stores directed edges between services with source, target, dependency type, and a confidence score. When something fails, the API runs a breadth first traversal querying edges at each depth level. That means recursive CTEs, multi hop joins, foreign key constraints, and composite indexes filtered by confidence.

I looked at whether DynamoDB could work for this. It probably could for simple lookups, but the traversal pattern really wants relational joins. You need to query "give me all services that depend on X with confidence above 0.3" and then for each of those, do it again. Doing that with single key lookups and application level iteration felt wrong.

There's also a data integrity angle. The dependencies table has check constraints that prevent self dependencies, enforce valid dependency types, and keep confidence scores in the 0 to 1 range. There's a unique constraint on source, target, and type so you don't get duplicate edges. If your graph gets corrupted, your blast radius calculation gives wrong answers, and wrong answers during an incident are worse than no answers.

The revenue calculation

Each service has a traffic snapshot with revenue per minute, conversion rate, and average order value. When the blast radius runs, it joins those snapshots against the affected services to sum up total revenue at risk. Filtered to customer facing services only. That's a pretty standard relational query but it only makes sense if your data model is structured correctly.

Serverless connections

One thing that was annoying to figure out was the connection handling. Vercel serverless functions are stateless, so every invocation could potentially open a new database connection. Aurora has connection limits. The solution was RDS Proxy sitting between Vercel and Aurora, multiplexing function calls into a small connection pool. Without that you hit "too many clients" errors pretty fast.

The app uses Drizzle ORM for type safe queries and schema management. Connection pool is set to 5 with SSL and keepalive. Statement timeout at 30 seconds so runaway queries fail fast instead of hanging.

The frontend

Next.js App Router deployed on Vercel. The dependency graph renders on Canvas with a force directed layout. There's a simulate failure feature that lets you pick any service and watch the cascade happen, nodes change color by depth, edges light up, the revenue counter starts ticking.

For the AI piece I hooked up AWS Bedrock. When an incident is active, the summary endpoint queries the database for root cause, blast radius, upstream candidates, and revenue impact, then sends all of that to Bedrock for a structured analysis. It returns a headline, root cause breakdown, and fix priority ranking.

What I'd do differently

The graph layout could be better. I went with a basic force simulation and it works for 14 services but I'd want something more structured at scale, probably a hierarchical layout with infrastructure at the bottom and customer facing at the top. Also the revenue model is pretty simplistic right now, real traffic data is messier than what I seeded.

The app is live if you want to try it: faultline-yzhl.vercel.app

This post was created for the purposes of entering the H0 Hackathon.

H0Hackathon

Every AI finance app wants your data. I didn’t trust that — so I built my own. Offline.

Arun — Wed, 22 Apr 2026 14:27:55 +0000

What I Built

If you spend any time browsing AI finance tools right now, you'll quickly realize that half of them are just shiny, sleek UI wrappers designed to do one thing: beg you to paste your portfolio data into their cloud servers.

I don't know about you, but the idea of handing my financial watchlist over to a random startup's black box just didn't sit right with me. So, I decided to ignore the SaaS products and build my own setup from scratch.

What I ended up with is a fully local, AI-powered market assistant. It’s a hybrid beast—part retro terminal CLI, part clean web dashboard. It silently tracks live stock prices in the background, runs deep sentiment analysis on market news, and actively pings me on Telegram and WhatsApp the second it thinks it's time to hold or buy.

The entire core idea revolves around absolute, uncompromising privacy. The whole "brain" of this operation runs directly on my laptop. None of my data, my watchlists, or my trading logic ever leaves my machine. There are no expensive monthly API subscriptions to OpenAI or Anthropic, and no cloud servers analyzing my trades. It's just a local pipeline crunching numbers in the background, and honestly, it feels incredibly cool to have that kind of autonomy.

For those of you who live in the terminal, here is exactly what the CLI output looks like when you point it at a watchlist and let it do its thing:

$ openclaw scan --watchlist AAPL,TSLA,NVDA

[09:31:02] Fetching live data...
[09:31:04] Running analysis (local)...
[09:31:07] Scanning 3 tickers...

  NVDA  │ BUY   │ Score: 87/100 │ Volume spike +23%
  AAPL  │ HOLD  │ Score: 54/100 │ Consolidation phase
  TSLA  │ HOLD  │ Score: 41/100 │ Mixed signals

✅ Notifications sent → Telegram + WhatsApp

How It Works

I wanted the pipeline to be ruthless in its efficiency but straightforward enough that I could actually explain it to someone. It breaks down into five distinct phases:

Data collection: First things first, I need the numbers. I pull live prices, volume metrics, and moving averages from free financial APIs like Alpha Vantage and Finnhub. To keep things fast and avoid getting blocked, everything gets cached straight into a local SQLite database.
Sentiment analysis: Numbers only tell half the story. The system reaches out and grabs recent news headlines for every ticker on my watchlist. It bundles all that text up and feeds it to the local LLM essentially to read the "vibe" or mood of the market that day.
Correlation: This is the part I think is actually really cool. The system actively forces the LLM to correlate the soft, fuzzy sentiment data (how the news sounds) with the hard, undeniable technical data (actual price action and volume spikes).
Decision: Based on that correlation, the LLM isn't allowed to write a summary. It has to output a strict, no-nonsense verdict: BUY, HOLD, or SELL, alongside a hard confidence score from 0 to 100.
Reporting: If a signal manages to cross my pre-set confidence threshold, it triggers an alert. A cleanly formatted message gets pushed directly to my phone via Telegram and WhatsApp bots, while the web dashboard quietly logs the history for me to review later.

My Experience

I want to be completely honest here: I am not a trader. Not even close. I went into this project knowing almost nothing about how real markets operate.

Surprisingly, that ended up being my biggest advantage. I didn't have any bad trading habits to unlearn, and I wasn't trying to force the AI to fit some preconceived trading strategy.

The coding part was an absolute blast, but the actual learning curve was humbling. I quickly realized I couldn't just type "tell me if this stock is good" into a prompt. I had to sit down, read up on what moving averages actually represent, and understand why volume matters before I could even construct a prompt that made sense to the AI.

The biggest problem I faced by far was hallucinations. Early on in the build, the local LLM confidently told me to buy a specific stock because of a "massive volume spike." I got excited, checked the raw data myself, and realized there was no spike. The AI had completely fabricated the number just to sound authoritative and confident.

That was a massive reality check. I had to go back and build an entirely separate Python verification layer just to double-check the AI's reasoning against the actual math before I allowed any notification to reach my phone. It felt like building guardrails for a very enthusiastic but slightly delusional robot.

I built this because I wanted to master data pipelines, but mostly I built it because I genuinely believe you shouldn't have to trade your personal financial data just to get a simple alert that a stock is moving.

OpenClaw Features Used

I tried building this with pure Python at first, and the code quickly turned into spaghetti. OpenClaw ended up being the absolute glue that held this entire chaotic pipeline together. Here is exactly how I used it:

Multi-agent pipeline: Instead of one massive script, I used OpenClaw to separate my logic into distinct, focused agents. I have a "Data Fetcher" agent whose only job is getting numbers, a "Quant Analyzer" agent to do the math, and a "Notifier" agent. OpenClaw manages the handoffs and communication between them seamlessly.
Local LLM (Ollama): I am running a local model via Ollama. Instead of spending days writing custom boilerplate to handle streaming, timeouts, and prompt routing, I just used OpenClaw's native integration. I point it at my local model, and it just works.
Structured decision system: LLMs love to talk. They want to explain their reasoning in paragraphs. I needed strict data. I used OpenClaw's structured output constraints to essentially wrestle the AI into returning exact JSON formats ({"signal": "BUY", "confidence": 85}). If the LLM tries to get chatty, OpenClaw flat-out rejects the response and forces a retry.

Try It Yourself

If you want to run your own completely private, local quant desk just for the fun of it, the code is entirely open-source. I warn you, it might be a little janky in places—but that's the beauty of building in public.

You can check out the repository, read through the setup guides, and get it running on your own machine right here:
OpenClaw Finance Assistant on GitHub