The Problem
Modern applications often consist of multiple interconnected microservices. When one service fails, the impact can spread through its dependencies and cause cascading errors across the system.
Finding the original cause can require engineers to inspect logs, trace dependencies, and correlate evidence across multiple services. TRACEFORGE AI is my project to make this investigation process more structured and easier to follow.
Introducing TRACEFORGE AI
TRACEFORGE AI is an AI-assisted incident investigation tool designed to help engineers explore service dependencies, investigate cascading failures, and identify potential root causes.
The application brings together a service topology, graph-query exploration, incident investigation context, and recommended remediation actions. Its goal is to help engineers move from an alert toward an evidence-informed hypothesis and a practical next step.
Why Graphs?
Microservice architectures naturally contain relationships: an API gateway communicates with downstream services, checkout depends on payment processing, and authentication components may depend on caches or other infrastructure.
Representing these relationships as a graph makes it possible to explore how services are connected and which dependencies may be relevant to an incident.
TRACEFORGE AI models services as graph nodes and their dependencies as relationships. Cypher-style graph queries can then be used to explore connected services and investigate possible failure propagation.
Where FalkorDB Fits
The backend includes a native FalkorDB client intended for graph-backed operations. FalkorDB is relevant to this project because graph queries provide a natural way to represent service dependencies and traverse relationships during incident investigation.
The project also includes an in-memory Cypher engine as a fallback for environments where a live FalkorDB server is unavailable. At the time of writing, the public deployment uses this fallback, and live FalkorDB connectivity has not yet been verified in the deployed environment. This distinction is important when evaluating the current demo.
Investigation Workflow
The TRACEFORGE AI demo showcases the following workflow:
- Incident overview: Review an incident and its reported symptoms.
- Service topology: Explore the graph of connected services and their dependencies.
- Graph query exploration: Examine dependency relationships using graph-query concepts.
- Incident investigation: Organize available evidence and investigation findings into potential root-cause hypotheses.
- Remediation recommendations: Present possible next steps while keeping remediation decisions under human control.
The intention is not to replace engineers. It is to provide a more organized starting point for investigating complex incidents.
Challenges and Lessons Learned
One important engineering lesson is that a working application interface does not automatically prove that its intended database is connected and being used by the deployed service.
A graph-backed application needs clear configuration, reliable connection handling, useful fallback behavior, and a way to verify which backend is active. A fallback can keep a demo usable, but it should not be confused with a successful live database connection.
I also learned the importance of making investigation results understandable. Showing service relationships, evidence, hypotheses, and recommended actions helps make an AI-assisted workflow easier for engineers to review.
What's Next?
The next steps for TRACEFORGE AI include verifying live FalkorDB connectivity in a configured environment, strengthening end-to-end tests against the actual graph database, and improving the traceability between graph-query results, incident evidence, and remediation recommendations.
Conclusion
TRACEFORGE AI explores how graph-based dependency analysis can help engineers investigate cascading microservice failures. By combining service relationships with an AI-assisted investigation workflow and human-reviewed recommendations, the project aims to make incident response more structured and understandable.
The project is a work in progress, and verifying the live graph-database path is an important part of making the deployment match the intended architecture.
Top comments (0)