🌊 What If One Microservice Fails? Building RIPPLE — An AI Agent That Investigates the Ripple Effect

Narasimha Lakshmi — Sat, 17 Oct 2026 20:09:27 +0000

Exploring graph-powered reasoning, MCP, and AI agents for the FalkorDB Graph Hacks hackathon.

Imagine you're managing a distributed application with dozens of interconnected services. Suddenly, the Inventory Service fails.

Will the Order Service be affected? Could Shipping experience downstream issues? Which business workflows might be disrupted?

Finding these answers isn't always straightforward. In a system with many dependencies, understanding the potential impact of one failure can require tracing multiple relationships across the infrastructure.

That's the problem I'm exploring with RIPPLE — AI What-If Impact Investigator, my project for Track 1: Agents That Act on Connected Data at the FalkorDB Graph Hacks hackathon.

🔗 Explore the project: Github

The central idea is simple: instead of asking an AI model to guess what might break, give it access to a connected graph of system dependencies and let it investigate.

💡 The Idea Behind RIPPLE

Traditional monitoring helps engineers identify unhealthy services and investigate incidents. But understanding how a failure could propagate through interconnected services is a different challenge.

I wanted to build a system where a user could ask a question such as:

«"What happens if the Inventory Service fails?"»

RIPPLE uses the dependency graph to identify potentially affected services, trace the paths connecting them to the simulated failure, and surface related business workflows.

Rather than returning only a natural-language answer, the system provides graph-backed paths that users can inspect.

That's the core idea behind RIPPLE: turn connected system knowledge into an explainable what-if investigation.

🕸️ Why FalkorDB?

The project is built around the idea that infrastructure is inherently connected.

A service may depend on another service, read from a database, communicate with an API, or participate in a business workflow. Representing these relationships as a graph makes it possible to investigate connections across multiple hops.

RIPPLE uses FalkorDB to represent these entities and relationships.

The current graph includes services, databases, APIs, queues, teams, and workflows, connected through relationships such as "DEPENDS_ON", "READS_FROM", "CALLS", and "REQUIRES".

For example:

"Order Service → Inventory Service"

This relationship gives RIPPLE a concrete path to investigate when simulating an Inventory Service failure.

A longer dependency chain can reveal downstream connections that would be missed by examining only direct dependencies.

🔬 Let's Simulate a Failure

For the current demo, I selected Inventory Service as the failed service.

RIPPLE traverses the graph and identifies three potentially affected services:

Service| Distance from failure
Order Service| 1 hop
Shipping Service| 2 hops
Analytics Service| 2 hops

The investigation also identifies related workflows:

Customer Checkout — criticality 5/5
Order Fulfillment — criticality 4/5

The dashboard presents these results through an interactive impact-propagation view, allowing users to explore the affected services and their dependency paths.

[Insert Screenshot 1: Impact Propagation view showing Inventory, Order, Shipping, Analytics, and affected workflows.]

An important distinction: these are results from the current modeled graph. They describe potential impact under the simulation, not verified predictions of actual production failures.

🔎 Beyond Finding Affected Services: Explain the Path

Identifying an affected service is useful. Understanding why it was identified is even more useful.

RIPPLE retrieves dependency paths from FalkorDB and uses them to explain the connection between the simulated failure and potentially affected services.

The dashboard also includes a Risk & Path Explanation Audit, which displays information such as:

Dependency paths and hop distances.
Degree-centrality classification based on graph relationships.
A heuristic prioritization score.
Severity categories to help organize investigations.

The current heuristic score is:

"round((criticality / 5) × 70 + 30 / hops)"

This score helps prioritize investigation; it is not a calibrated probability of failure.

Keeping this distinction visible is important. A graph path establishes a modeled dependency, but it doesn't automatically prove that a real outage occurred or that a failure will propagate.

[Insert Screenshot 2: Risk & Path Explanation Audit showing the selected service, dependency path, and heuristic scoring details.]

🧠 Bringing in AI Agents with MCP

A graph query can retrieve connected information, but I also wanted users to be able to investigate the system through natural-language questions.

That's where the AI agent and the Model Context Protocol (MCP) come in.

I implemented an MCP server using the official MCP SDK and connected it to the Node.js backend through an MCP client. The server exposes five tools:

MCP tool| What it does
"list_services"| Lists services in the graph
"analyze_impact"| Investigates the potential impact of a service failure
"get_dependency_path"| Finds dependency paths between services
"get_workflows"| Retrieves related business workflows
"get_graph_summary"| Summarizes graph nodes and relationships

The Groq-powered agent can discover available tools and use them to investigate questions. This allows the language model to retrieve structured information from the graph rather than relying solely on its pretrained knowledge.

The technologies work together as follows:

FalkorDB stores the connected system context.
MCP exposes graph operations as structured tools.
Groq powers the natural-language agent.
Node.js and Express provide the backend APIs.
React provides the interactive dashboard.

I've tested the five MCP tools individually against the current graph, including impact analysis and dependency-path retrieval.

[Insert Screenshot 3: Full RIPPLE dashboard showing the AI agent alongside the graph.]

⚙️ Challenges and Lessons Learned

Building RIPPLE has been a useful reminder that an AI agent is more than an LLM connected to a prompt.

Some of the important engineering challenges include:

Modeling relationships correctly: Dependency direction matters. Traversing the graph incorrectly can lead to misleading impact results.

Supporting multi-hop analysis: The system needs to follow connected paths while respecting a configurable hop limit.

Connecting the agent to real tools: MCP provides a structured way for the agent to discover and invoke graph operations.

Keeping explanations grounded: The system should distinguish graph evidence from assumptions and heuristic scores.

Handling invalid inputs: Unknown service IDs and invalid parameters need predictable, understandable error responses.

These details matter because an investigation system should be inspectable and reliable, not merely convincing in a successful demo.

🚀 What's Next for RIPPLE?

I'm continuing to strengthen the implementation, with a focus on:

Improving error handling and end-to-end testing.
Refining the graph and propagation visualization.
Making agent explanations easier to inspect.
Expanding realistic what-if scenarios.
Improving the investigation experience from question to evidence.

A future direction is to connect the graph with continuously updated infrastructure information and operational signals. That would require additional integrations and validation beyond the current graph-based simulation.

🌊 Why This Fits Track 1

The exciting part of Track 1: Agents That Act on Connected Data is the opportunity to move beyond agents that only generate text.

RIPPLE explores how an agent can use connected data, select structured tools, investigate multi-hop relationships, and return explanations supported by graph paths.

The graph supplies the context. MCP makes its capabilities available to the agent. The application turns the investigation into something engineers can explore.

My goal is to make it easier to answer a practical question:

When one component fails, what else could be affected—and how can we trace the connection?

That's RIPPLE: one simulated failure, multiple dependencies, and a ripple effect worth investigating. 🌊

💬 Let's Discuss

If you could give an AI agent access to your application's dependency graph, what would you want it to investigate first?

Service failures? Security incidents? Infrastructure changes?

I'd love to hear your ideas.

FalkorDB #AIAgents #MCP #GraphDatabases #Hackathon #BuildInPublic

DEV Community: Narasimha Lakshmi

🌊 What If One Microservice Fails? Building RIPPLE — An AI Agent That Investigates the Ripple Effect

FalkorDB #AIAgents #MCP #GraphDatabases #Hackathon #BuildInPublic