Design a Massive Graph Database for E-Commerce

Problem statement

Design a massive graph database for an e-commerce marketplace. The graph models users, products, brands, and product categories as nodes, with edges for relationships: purchases, ratings, follows, brand tags, category membership, and derived similarity. On top of this graph the platform must answer BFS-based exploratory queries, item-to-item similarity via graph distance or embeddings, shortest-path relationship discovery, and subgraph extraction for marketing analytics.

A relational database can store orders and reviews. What it cannot do efficiently is answer “show me, within three relationship hops of product P, the brands most often purchased by users who rated P highly” at millisecond-to-sub-second latency over tens of billions of edges. That query is a traversal. Its cost on row-store joins grows exponentially with hop depth; its cost on an adjacency-indexed graph store grows with the result set, not with the table size. That asymmetry is the entire reason this system exists.

Why this problem is distinctive

E-commerce graphs have three properties that dominate the design. First, a power-law degree distribution: a tiny number of hub products, celebrity brands, and category nodes carry millions of edges while the median product carries a few hundred. Naive partitioning by node id puts all hubs on random shards and melts them. Second, a heavily skewed read/write ratio: catalog and relationship structure change slowly, but purchase and rating edges stream in continuously from order events; reads dominate by more than an order of magnitude. Third, two very different consumers: online services that need bounded-depth traversals in under 100ms, and offline analytics that need full-graph iterative algorithms such as PageRank, connected components, and random-walk embeddings.

The design therefore splits cleanly into four planes. An ingestion plane turns order, rating, follow, and catalog events into typed edge mutations. A serving plane stores adjacency lists behind a partitioned index and executes bounded traversals. An algorithm plane runs iterative graph jobs offline and writes derived edges and embeddings back. A governance plane handles schema versioning, edge TTL, PII classification, and access control.

Stated scale baseline versus published references

Public evidence anchors the problem in reality. Meta's TAO paper reports a social-graph store holding roughly one trillion associations with a read-to-write ratio around 500:1 and consistency achieved by making the datastore a read-through cache over MySQL (USENIX ATC 2013). Pinterest published GraphSAGE-based embeddings over billions of pins and edges for related-item discovery (KDD 2017). Amazon has publicly reported hundreds of millions of active customer accounts and hundreds of millions of products, with recommendation systems attributed in industry analyses to a substantial fraction of sales. These are cited reference points, not our design targets.

For capacity planning this answer explicitly assumes a mature marketplace with 500 million registered users, 60 million daily active users, 800 million product nodes, 12 million brands, 40 million category/tag nodes, roughly 33 billion edges, 500K average traversal reads per second with a 3x event peak, and 40K edge writes per second average. Unless tied to a citation, every number is a stated assumption.

What separates a strong answer

A shallow answer says “use Neo4j” and stops. A strong answer explains the adjacency storage layout, the partition strategy that survives hub nodes, the consistency contract per edge type, the traversal execution engine with frontier deduplication and timeouts, the cache hierarchy for hot hubs, and the offline pipeline that turns raw edges into similarity scores. It also states what the graph is not: it is not the system of record for orders or payments; it is a derived, event-sourced index over them, rebuilt from the source-of-truth systems when needed.