Graph Databases¶

11:02 AM. A $4,200 payment just posted. Risk needs an answer in under 200 ms: does this user share a device, IP, or card with a known fraud ring, and does that ring also hit the same merchant cluster — a few hops out, on a graph of tens of millions of entities?

Which system answers that, at that latency?

A. The warehouse — run an aggregate query grouped by fraud ring. B. Postgres — join Users, Devices, IPs, Transactions, Merchants for this one user. C. A graph store — start at the user node and traverse typed edges a few hops out. D. Postgres, but with a covering index on every foreign key involved.

Pick one before reading on. The warehouse can count fraud by country; Postgres can fetch the user's last 20 transactions; neither wants to walk User → Device → IP → Transaction → Merchant at request time. When the product question is the path, not the row, you model a graph. When the question is a scan or a join of two tables, you do not.

What this module covers¶

Read in that order. Cypher without modelling produces supernodes. Algorithms without a split between online traversal and offline GDS produce a locked cluster.

Running use cases¶

Fraud (primary).

(User)-[:USED]->(Device)
(User)-[:USED]->(IP)
(User)-[:MADE]->(Transaction)-[:AT]->(Merchant)
(Transaction)-[:FROM]->(IP)
(Transaction)-[:ON]->(Device)

Analysts: “accounts within 3 hops of this IP.” Nightly: weakly connected components as candidate rings. Recs-adjacent: “merchants similar to merchants this ring hits.”

Recommendations (secondary). User–Product–User, or User–Merchant–User. Often not the production recsys (that is embeddings + two-towers). Graph is the explanation and the cold-start neighbourhood, or a GDS similarity job — not a replacement for the feature store.

Also in this academy, briefly: IAM trees, data lineage. Same modelling rules; less operational heat than fraud.

The system of record for payments remains Postgres. The graph is a derived projection, rebuilt from CDC/Kafka. See Fraud architecture.

Central intuition¶

graph LR
    U1[User Alice]
    U2[User Bob]
    D[Device iPhone]
    IP[IP 203.0.113.42]
    T[Txn 500]
    M[Merchant Coffee]

    U1 -->|USED| D
    U2 -->|USED| D
    U1 -->|MADE| T
    T -->|FROM| IP
    T -->|AT| M

A JOIN looks up a key in another table (index seek × fan-out per hop). A traversal walks adjacency already stored on the node (pointer chasing). After 3–4 hops with fan-out 50, SQL plans explode; Cypher stays a pattern. After 1 hop, Postgres wins on simplicity and often on latency.

Graph databases are operational stores for neighbourhood queries. Graph algorithms (WCC, PageRank, similarity) are analytics on a projection — usually Graph Data Science in memory, or Spark GraphX, not a MATCH on the live serving graph at every payment.

When you are in the wrong module¶

Stay in Postgres / OLAP if:

• “Orders for this customer” (1 hop)
• “GMV by country” (scan + aggregate)
• “Does this FK exist?” (constraint)

Stay here if:

• Variable-depth path queries are the product
• You need rings, bridges, similar nodes as first-class answers
• SQL recursive CTEs are the proposed 4-hop implementation

Graph vs relational is the decision page. Use it in design reviews.

How the fraud path actually splits¶

flowchart TD
    PG["Postgres\nledger"]
    K["CDC / Kafka"]
    N["Neo4j\nOLTP graph"]
    GDS["GDS projection\nWCC / PageRank / similarity"]
    CH["ClickHouse\nrates, dashboards"]
    API["Payment risk API\n2-hop lookup"]

    PG --> K
    K --> N
    K --> CH
    N --> API
    N -->|"nightly / on demand"| GDS
    GDS --> CH

Mental model to finish with¶

Failure preview¶

• Unbounded * traversals that walk the company.
• Treating WCC as a per-payment query.
• Modelling every SQL table as a node (join tables become supernodes).
• No uniqueness constraints; duplicate User nodes break rings.
• Running PageRank on the live cluster at noon.

Traversal vs algorithm vs scan¶

Keep these three words in the same design doc:

Recommendations sit on the same split: live 3-hop “people who bought also bought” is a traversal you should precompute; item–item similarity is an algorithm; “top sellers this week” is a scan.

If a proposal uses one cluster for all three, it will fail the SLO of at least one.

What you will be able to do¶

After the five pages:

• Look at a 4-hop SQL CTE and say whether it is a graph problem or a missing pair table.
• Choose transaction-as-node vs transaction-as-edge from a query list.
• Write Cypher that starts with an index, names types, caps depth, and PROFILEs.
• Schedule WCC → PageRank-on-component → similarity so they do not touch the payment path.
• Tell a VP that Postgres still owns money.

How to study this module¶

1. Read the 3-hop SQL vs Cypher on Graph thinking. Time both in your head at fan-out 30.
2. Model fraud twice on Graph modelling (transaction as node vs relationship).
3. Write Cypher with indexes and PROFILE on Neo4j.
4. Place WCC / PageRank / similarity on a clock on Graph algorithms.
5. Defend Postgres on Graph vs relational.

Related modules¶

• Fraud architecture
• E-commerce architecture
• NoSQL thinking — another query-bound model
• Spark — GraphX / large projections
• Selection framework