Design a Recommender for Bundled Products

Problem statement

Design a recommender that suggests product bundles frequently bought together — for example, a laptop with a wireless mouse and a carry case — displays them on relevant product pages, lets the shopper add the whole bundle to the cart with one click at a discounted bundle price, and guarantees the offer respects live stock for every item in the bundle.

This is not a generic recommendation engine. A normal recommender returns a ranked list of independent items; the shopper picks zero or more, and each item is priced and stocked separately. A bundle is an atomic multi-SKU commercial offer: it has its own identity, its own joint price, a discount that only applies when all items are purchased together, and an availability rule that fails if any single component SKU goes out of stock. That single difference changes the entire architecture, because the bundle must stay coherent across three systems that normally do not talk to each other at recommendation time: the mining pipeline that discovers the affinity, the pricing engine that computes the discount, and the inventory service that validates stock.

Why the problem is distinctive

A generic recommender can tolerate a stale impression: if a suggested item sells out, the shopper simply ignores it or sees a disabled tile later. A bundle cannot. If we show laptop + mouse + case at a 15% combined discount, and the mouse sells out between page render and add-to-cart, we either break the discount promise, add an incomplete bundle to the cart, or silently remove the discount and surprise the shopper at checkout. All three are conversion and trust failures. So the design must treat bundle eligibility as a continuously re-validated property, computed cheaply at serve time and re-checked transactionally at cart-add time.

The problem requires four functional capabilities: identifying frequent co-purchases through data mining, displaying bundle suggestions on product pages, one-click add-to-cart with discount, and per-item stock updates. It also requires four quality attributes: a batch or streaming mining approach, consistency when an item goes out of stock, scalability for real-time recommendation updates, and A/B testing to measure bundle uptake.

Public operating baseline versus design assumptions

Amazon's Frequently Bought Together feature, described in Linden, Smith and York's 2003 IEEE Internet Computing paper on item-to-item collaborative filtering, is the canonical production bundle recommender: it scales to hundreds of millions of customers and tens of millions of items by precomputing item-item affinity offline and rendering it with light online checks. Industry analyses commonly attributed to McKinsey estimate that roughly a third of Amazon's revenue is influenced by recommendation features, which is why bundling is worth a dedicated architecture rather than a widget bolted onto a generic engine. Instacart's engineering blog describes inventory-aware ranking where availability signals feed the recommendation loop because a recommended item that cannot be fulfilled is a negative experience. These are published reference points, not our design targets.

For capacity planning, this answer explicitly assumes a mid-size marketplace with 8 million daily active users, a 20 million SKU catalog, 120 million product detail page views per day, and 1.8 million orders per day. Every number not tied to a named company is a stated design assumption.

The four architectural planes

1. Mining plane: discovers co-purchase affinity from order history using batch and near-real-time signals, produces scored bundle candidates.
2. Serving plane: stores published bundles per anchor SKU and returns eligible bundles for a product page within a strict latency budget.
3. Commerce plane: validates inventory, computes the bundle price, applies the discount, and writes the bundle into the cart as a coherent unit.
4. Experimentation plane: assigns shoppers to bundle strategies, measures attach rate, AOV lift, and margin impact, and gates promotion.

A strong answer keeps these planes separate. The serving plane may degrade or disappear without breaking the product page. The commerce plane must never be degraded: a bundle enters the cart only when every item is in stock and the price is confirmed.