The Problem Nobody Talks About
You have a microservices architecture with 50 services. A deployment went sideways and you need to figure out which service is the single point of failure, which groups of services are tightly coupled, and which service — if it goes down — takes the most other services with it.
Or maybe you're building a recommendation engine. You have users, items, and interactions between them. You need to rank items by importance, not just by raw interaction count, but by how important the users who interact with them are.
Or you're managing a project with 30 tasks and complex dependencies. You need the critical path, the bottlenecks, and a way to group related tasks into workstreams.
The textbook answer to all of these: deploy Neo4j (or Amazon Neptune, or TigerGraph). Model your data as nodes and edges. Learn Cypher. Write queries. Maintain infrastructure. Pay for hosting. The pragmatic answer: you need three algorithms.
PageRank tells you importance. Louvain tells you communities. Shortest path tells you critical paths and bottlenecks.
You don't need a graph database for graph analytics. You need the algorithms. And for the vast majority of real-world use cases — graphs with dozens to thousands of nodes — running these three algorithms on demand is faster, cheaper, and simpler than standing up and maintaining a graph database.
Let me walk through each algorithm, explain when you'd use it, and show a working example that you can run right now.
Three Algorithms, Explained Simply
PageRank — "Who Matters Most?"
Google built their empire on this algorithm. The insight is recursive: a node is important if important nodes point to it. A web page linked by the New York Times matters more than one linked by a random blog. A microservice depended on by your API gateway matters more than one depended on by an internal logging tool.
PageRank isn't just for web pages. It works on any directed graph. Use cases include:
- Infrastructure: Which service, if it goes down, causes the most cascading failures?
- Influence mapping: Which person in an organization is the most influential (not by title, but by actual dependency patterns)?
- Content ranking: Which document in a knowledge base is referenced most by other important documents?
The algorithm iterates until convergence: each node distributes its current rank equally across its outgoing edges, and receives rank from incoming edges. A damping factor (usually 0.85) prevents rank from concentrating in cycles.
Louvain Community Detection — "What Belongs Together?"
Louvain finds natural clusters by optimizing modularity — a measure of how densely connected nodes within a group are compared to connections between groups. The algorithm is greedy and hierarchical: it starts with each node in its own community, then merges communities that improve modularity, repeating until no further improvement is possible.
What makes Louvain practical is that it's fast (near-linear time complexity) and requires zero configuration. You don't tell it how many clusters to find — it discovers them. Use cases include:
- Fraud detection: Find rings of accounts that transact heavily with each other but rarely with outsiders.
- Market segmentation: Cluster customers by their actual interaction patterns, not demographic assumptions.
- Codebase analysis: Identify tightly coupled modules that should be extracted into packages.
Shortest Path and Bottleneck Detection — "Where Are the Chokepoints?"
Dijkstra's algorithm finds the lowest-cost path between two nodes. That's useful on its own for critical path analysis, but the real power comes from bottleneck detection: identify nodes where many paths converge.
A bottleneck node has high in-degree (many things flow into it) and high PageRank (it's important) but relatively low out-degree (it's a funnel). The bottleneck score formula — PageRank * (inDegree + 1) / (outDegree + 1) — surfaces these chokepoints. Use cases include:
- Supply chain risk: Which supplier, if disrupted, breaks the most downstream processes?
- Project management: Which task is on every critical path and has no parallel alternative?
- Network reliability: Which router handles the most cross-segment traffic?
Real Example: Ranking and Clustering a Dependency Graph
Let's take a common scenario: five components in a system with dependency relationships. We want to know which component is most critical, how the components cluster, and where the bottlenecks are.
Here's a working API call you can run right now:
curl -X POST https://oraclaw-api.onrender.com/api/v1/analyze/graph \
-H "Content-Type: application/json" \
-d '{
"nodes": [
{"id": "auth", "type": "action", "label": "Auth Service", "urgency": "high", "confidence": 0.9, "impact": 0.9, "timestamp": 1711350000},
{"id": "api", "type": "action", "label": "API Gateway", "urgency": "high", "confidence": 0.8, "impact": 0.8, "timestamp": 1711350000},
{"id": "db", "type": "action", "label": "Database", "urgency": "medium", "confidence": 0.7, "impact": 0.9, "timestamp": 1711350000},
{"id": "cache", "type": "action", "label": "Cache Layer", "urgency": "low", "confidence": 0.6, "impact": 0.5, "timestamp": 1711350000},
{"id": "frontend", "type": "goal", "label": "Frontend", "urgency": "medium", "confidence": 0.8, "impact": 0.7, "timestamp": 1711350000}
],
"edges": [
{"source": "frontend", "target": "api", "type": "depends_on", "weight": 1.0},
{"source": "api", "target": "auth", "type": "depends_on", "weight": 0.9},
{"source": "api", "target": "db", "type": "depends_on", "weight": 0.8},
{"source": "api", "target": "cache", "type": "depends_on", "weight": 0.5},
{"source": "auth", "target": "db", "type": "depends_on", "weight": 0.7}
]
}'
Reading the Response
PageRank reveals that db (Database) has the highest rank. This makes intuitive sense — both api and auth depend on it, and api itself is depended on by frontend. The database sits at the bottom of the dependency chain, and importance flows downhill. Meanwhile, frontend has the lowest PageRank because nothing depends on it.
Communities split the graph into two natural clusters. One cluster groups frontend, api, and cache — the "request-serving" layer. The other groups auth and db — the "data and identity" layer. Louvain found this structure automatically, with no configuration. If you were splitting your monolith into two deployable units, this is where you'd draw the line.
Bottlenecks show that api has the highest bottleneck score. Three edges flow into or through it, but its outgoing connections fan out to three different services. It's the classic single point of failure — the funnel that every request must pass through. If you're investing in redundancy, api is where to start.
This analysis runs in under 25 milliseconds. No database to provision, no query language to learn, no infrastructure to maintain.
Other Use Cases
These same three algorithms apply far beyond infrastructure graphs:
Recommendation ranking. Build a bipartite graph of users and items. Run PageRank — items connected to high-PageRank users surface as recommendations. This is how early collaborative filtering worked, and it's still effective for cold-start scenarios.
Fraud detection. Model transactions as edges between accounts. Run Louvain — fraud rings show up as tight communities with unusually high internal transaction volume relative to external connections.
Project management. Model tasks as nodes and dependencies as edges. PageRank identifies the most critical tasks (those that block the most downstream work). Shortest path gives you the critical path through the project. Bottleneck detection flags tasks that need extra resources or contingency plans.
Knowledge graphs. Connect concepts, documents, or entities. PageRank surfaces the most referenced concepts. Louvain groups related topics. Shortest path finds the connection between any two concepts — useful for "explain how X relates to Y" features.
When You Need More
These three algorithms have limits. If you're working with billions of edges, you need a distributed graph engine like Apache Spark GraphX or Neo4j. If you need streaming graph updates with real-time traversals, you need a proper graph database. If you need complex pattern matching (find all triangles, match subgraph patterns), Cypher or Gremlin gives you query expressiveness that no API can replicate.
But be honest about your scale. Most graphs in application development have hundreds to low thousands of nodes. For those, spinning up a graph database is like renting a warehouse to store a bookshelf.
Bottom Line
Graph algorithms are powerful. Graph databases are overkill for most use cases. PageRank, Louvain, and shortest path cover roughly 80% of what developers actually need from graph analytics: rank things by importance, find natural clusters, and identify bottlenecks.
The example above uses OraClaw's graph analysis endpoint, which runs all three algorithms in a single call using the graphology library under the hood. It's free, stateless, and takes under 25ms. But even if you roll your own — graphology plus graphology-metrics plus graphology-communities-louvain gives you everything shown here in about 280 lines of TypeScript.
The point isn't the tool. The point is that graph analytics shouldn't require a graph database. Three algorithms, one API call, instant answers.
Top comments (0)