In this chapter
We'll meet traversals, Cypher-style pattern matching, and filtering — walking a real, stored relationship directly instead of reconstructing it with a join — and land this Act's own core realization made mechanically real.
The Problem in Real Life
"Which accounts did ACC-4471 refer?" used to mean a query, a join, maybe two. Now Sarah just asks the graph to walk from that one account, outward, along REFERRED_BY relationships. It comes back instantly — not because the data is small, but because the connection was already there, waiting to be walked, not rebuilt.
Mike watches her write the query — barely a sentence, shaped almost like the sketch she drew last chapter.
That's it? It reads like you're just... describing the shape you're looking for.
Mike
Rebuilding a Connection vs. Walking One That Already Exists
A traversal walks a stored connection
Starting at a node and following real relationships outward — not recomputing them, just following what's already there.
Cypher reads like a picture of the pattern
MATCH (a)-[:TYPE]->(b) RETURN a, b describes the shape you're looking for, node-arrow-node, the same way it'd be sketched on paper.
Filtering narrows the pattern
A label or property added to a node pattern only matches nodes that satisfy it — the same filtering idea as every other database in this course.
No join, no rebuilding
The relationship walked by MATCH is the exact one written by CREATE — not reconstructed fresh on every query, the way a relational JOIN would be.
Traversals, Cypher & Pattern Matching
A traversal is exactly what it sounds like: starting at one or more nodes and walking outward along real, stored relationships to find what's connected. This is the literal mechanism behind last chapter's own keyInsight — a relationship being "data" isn't just a philosophical distinction, it's what makes walking it a direct operation instead of a computed one.
Cypher (and this simulator's own Cypher-flavored subset) makes a traversal look like a picture of what you're looking for. MATCH (a:Account)-[:REFERRED_BY]->(b:Account) RETURN a, b reads almost exactly like the sketch from last chapter: a node, an arrow, another node — pattern matching, describing the shape of a connection rather than the steps to compute it.
The MATCH line is the traversal: find every Account node a that has a REFERRED_BY relationship pointing to another Account node b, and return both. Filtering works the same way filtering already has in every database this course has covered — add a label or a property to a node pattern ((a:Account {name: 'Fresh Finds Co'})) and only matching nodes are considered.
CREATE (a1:Account {id: 'ACC-4471', name: 'Fresh Finds Co'})CREATE (a2:Account {id: 'ACC-8820', name: 'Green Basket'})CREATE (a1)-[:REFERRED_BY]->(a2)MATCH (a:Account)-[:REFERRED_BY]->(b:Account) RETURN a, b
The result's own summary line — "1 :REFERRED_BY relationship(s) matched" — is this simulator's honest stand-in for real Cypher's COUNT()/aggregation functions, which this teaching subset doesn't implement directly. The idea (a query can report how many matches it found, not just list them) is the same; the full aggregation syntax isn't.
This is where last chapter's distinction actually pays off. Finding "everyone ACC-4471 referred" relationally would mean a query that joins an accounts table to itself through a referrals table — reconstructing the connection from scratch, every single time it's asked. Here, the connection was never lost in the first place. MATCH doesn't rebuild the relationship between a1 and a2 — it walks the exact one that was written when the CREATE for that relationship ran.
This is also, precisely, what makes a fraud ring findable instead of just visible on paper. "Show me every account reachable by walking REFERRED_BY relationships starting from ACC-4471" is a traversal — a real, askable question — in a way it was never a practical one against a relational schema, where each additional hop meant another join.
Key Takeaway
In a graph database, the relationship isn't something you calculate later — the relationship itself is data, which is exactly why a traversal like this MATCH doesn't reconstruct a connection from scratch, it walks one that was already stored the moment it was created.
Why This Matters
Every remaining chapter in this Act is a variation on this exact mechanism. Fraud detection and shortest paths are traversals that go further than one hop; recommendations are the same MATCH shape, just walking a BOUGHT relationship instead of REFERRED_BY.
GreenMart can now walk a real relationship instead of only describing one on paper. One hop at a time isn't the whole fraud-ring story, though — following a chain of connections several hops deep, and finding the shortest one, is exactly where the next chapter goes.