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.
