Design a Category Tree & Navigation

Problem statement

Design a category tree and navigation system for an e-commerce platform. Merchandisers create and reorganize a hierarchical taxonomy of thousands of categories. Products are assigned to one or many categories. Shoppers browse through navigation menus, category landing pages, and drill-down paths. The tree changes continuously as the business adds seasonal departments, splits fast-growing subcategories, and runs region-specific assortments, while customer-facing reads must stay fast and consistent with search.

This looks like a simple tree problem until you measure it. The read-to-write ratio is extreme: navigation structures are edited a few hundred times per day but rendered tens of millions of times per day. A single category rename or move fans out to navigation menus, breadcrumbs, category pages, search facets, URL redirects, sitemap files, and regional variants. The hard engineering is not storing a tree; it is propagating tree changes to every derived surface without breaking the shopper experience, the search index, or SEO equity.

Why the problem is distinctive

A product record is owned by one write path. A category is owned by many consumers with different consistency needs. The merchandiser needs transactional editing with preview and rollback. The shopper needs a sub-100ms menu that never shows a dead link. The search engine needs facet counts that match the tree within a bounded lag. SEO needs stable URLs that survive restructuring. Localization needs per-market overlays without forking the whole tree. Treating these as one dataset with one consistency policy is the classic failure mode of this question.

The design therefore separates two planes. The editorial plane is a strongly consistent system of record for tree structure, product assignment, and merchandising metadata, with workflows, permissions, and audit. The customer plane is a fan-out of versioned, cacheable projections: navigation snapshots, category page payloads, breadcrumb indexes, and search facets. A change event moves data from the first plane to the second; nothing on the customer plane ever writes back.

Public operating baseline versus design assumptions

Public evidence establishes the scale of the category. Amazon reports more than 300 million active customer accounts and a catalog of hundreds of millions of products organized into browse nodes that products join many-to-many; Amazon's published architecture material describes browse trees as a structure distinct from search. eBay publicly describes a taxonomy of roughly 18,000 leaf categories with category-specific item attributes, and reported about 132 million active buyers in 2023. Shopify reported more than $11 billion in gross merchandise volume across its Black Friday Cyber Monday weekend in 2024, with millions of merchants each defining collections and menus. These are cited company figures for context, not requirements for our fictional system.

For capacity planning, this answer explicitly assumes a mature marketplace with 15 million daily active users, 40 million navigation views per day, a taxonomy of 12,000 categories across 5 depth levels, 50 million products carrying 90 million product-category edges, and 4 regional variants. Unless a number is tied to a citation, it is a stated design assumption, target, budget, or illustrative threshold.

The four architectural planes

1. Editorial plane: taxonomy CRUD, lifecycle state, permissions, preview, audit, rollback.
2. Propagation plane: change events, projections, cache versioning, search index alignment.
3. Serving plane: navigation APIs, category pages, breadcrumbs, CDN and edge caching.
4. Governance plane: localization overlays, SEO redirect maps, analytics, quality monitors.

A strong interview answer keeps these planes separate. It lets the editorial plane degrade without serving stale-but-safe navigation, and it lets the serving plane absorb a traffic spike without touching the system of record.