Recommendations & Graph Algorithms

In this chapter

We'll turn the same traversal mechanism toward recommendations, and meet graph algorithms this simulator doesn't implement (centrality, community detection) plus knowledge graphs and social networks as related use cases.

8–10 min

The Problem in Real Life

The fraud ring is handled. Mike looks at the same graph Sarah built to catch it and asks a completely different question: "couldn't this same idea tell a customer what to buy next?"

Sarah realizes he's right — a BOUGHT relationship is exactly the same shape as a REFERRED_BY one. Same database, same traversal mechanism, a completely different, friendlier use.

We built a fraud detector. Did we also just build a recommendation engine?

Mike

Catching a Ring vs. Suggesting the Next Purchase

"Also bought" is the same MATCH, different relationship

Walking BOUGHT instead of REFERRED_BY — the same traversal mechanism, a friendlier question.

Centrality and community detection go further

Finding the most-connected node, or a tightly-connected cluster, automatically — traversal at a scale beyond one MATCH at a time.

"Also bought" recommendations are the same traversal mechanism as fraud detection, walking a different relationship. Instead of REFERRED_BY or SHARED_DEVICE, the relationship is BOUGHT — and instead of looking for a suspicious ring, GreenMart is looking for a helpful overlap: who else bought the thing a customer is looking at, and what else did they buy?

On recommendations — the same MATCH, a friendlier question. "Who else bought Organic Apples" is one MATCH, filtered by product. "What else did Divya buy" is another MATCH, filtered by buyer. Run one after the other — as a real, honest two-step traversal, not a single hidden magic query — and the answer to "customers who bought this also bought" falls out naturally: find the other buyers, then find what they bought.
On graph algorithms beyond a single traversal. Real graph databases go further than one MATCH at a time. Centrality asks which nodes are the most connected or influential in the whole graph — the account at the center of a large referral network, or the product everyone's basket touches. Community detection finds tightly-connected clusters automatically — the fraud ring from earlier Acts is exactly a community, a group far more connected to each other than to the rest of the graph. This simulator doesn't implement either algorithm (they're real, more involved computations), but the concept builds directly on traversals already covered: centrality and community detection are really just "traverse a lot, and summarize the pattern," done at a scale a person can't do by hand.
On where this shows up beyond fraud and shopping. A knowledge graph is the same property graph idea applied to facts and how they relate — "this ingredient is used in this recipe, which belongs to this cuisine." A social network is the same idea applied to people and their connections. Different domain, same nodes-and-relationships shape this whole Act has been building.

First query: who else bought Organic Apples? Both Rohan and Divya did. Second query: what else did Divya buy? Rolled Oats. Chain the two together and the recommendation writes itself: someone who buys Organic Apples might also want Rolled Oats — found through two real, honest single-hop traversals, not one hidden multi-hop query this teaching subset doesn't implement.

Also Bought — Two Honest, Single-Hop Traversals

CREATE (rohan:Person {name: 'Rohan'})
CREATE (divya:Person {name: 'Divya'})
CREATE (apples:Product {name: 'Organic Apples'})
CREATE (almondMilk:Product {name: 'Almond Milk'})
CREATE (oats:Product {name: 'Rolled Oats'})
CREATE (rohan)-[:BOUGHT]->(apples)
CREATE (rohan)-[:BOUGHT]->(almondMilk)
CREATE (divya)-[:BOUGHT]->(apples)
CREATE (divya)-[:BOUGHT]->(oats)
MATCH (buyer:Person)-[:BOUGHT]->(item:Product {name: 'Organic Apples'}) RETURN buyer, item
MATCH (buyer:Person {name: 'Divya'})-[:BOUGHT]->(item:Product) RETURN buyer, item

None of this is free, and pretending otherwise would break this course's own established honesty about every database it's taught — the next chapter is exactly that honest close: what these algorithms cost, and when a graph database stops being the right tool at all.

Key Takeaway

The same traversal that catches a hidden fraud ring also powers a recommendation, a knowledge graph, or a social network — the mechanism doesn't change, only the relationship type and the question being asked.

Why This Matters

This closes the loop this Act's very first chapter opened with: GreenMart learned relationships could be data worth storing directly, and this chapter shows that the exact same mechanism — not a different database, not a different technique — powers both a security problem and a genuinely customer-friendly feature.

GreenMart now has a real recommendation mechanism and an honest sense of graph algorithms this simulator doesn't implement. The next chapter asks the harder, closing question: what does all of this cost, and when is a graph database the wrong tool entirely?