Design a Digital Coupons Aggregator

Problem statement

Design a digital coupons aggregator that collects coupon codes and deals from many retailers and affiliate networks, normalizes them into one searchable catalog, surfaces them through a deals website and a browser extension, tracks outbound clicks for affiliate attribution, and continuously validates whether codes still work. The business model is affiliate commission: when a shopper clicks through to a merchant and completes a purchase, the affiliate network pays us a percentage of the sale. That single sentence is what makes this more than a search engine — every offer is also a financial instrument with an owner, an expiry, a commission rate, and a measurable reliability.

This is not the same problem as a first-party store coupon system. A retailer designing its own promo codes controls issuance, redemption, and fraud. An aggregator controls none of those. We receive offers we did not create, from sources with inconsistent schemas, and we must answer two questions the source never answers for us: does this code still work, and is this click genuinely ours? The first question drives the validation plane. The second drives the attribution plane.

Why the problem is distinctive

Three properties separate this from a generic e-commerce search design. First, inventory decays. A catalog of 2.5 million offers can be 15% stale on any given day because merchants silently end promotions, exhaust usage limits, or change terms. Serving a dead code at checkout is the single fastest way to destroy trust, so freshness is a product invariant, not a nice-to-have. Second, the click is money. Outbound clicks and their conversions feed commission reconciliation with networks such as CJ Affiliate, Impact, Awin, and ShareASale. A lost click event or a misattributed conversion is a direct revenue leak and a contractual dispute waiting to happen. Third, ingestion is heterogeneous and adversarial: partner feeds arrive in different schemas and cadences, merchant sites change markup, and some sources are unreliable or even spammy.

Public operating baseline versus design assumptions

Public evidence establishes that the category is large and real. PayPal announced the acquisition of Honey for approximately $4 billion, closing in January 2020, at which point press coverage reported roughly 17 million members and automatic code application across tens of thousands of merchant sites. Rakuten acquired Ebates for $1 billion in 2014 and later reported more than 15 million members in its rewards program. RetailMeNot marketed coverage of tens of thousands of merchants before its 2020 sale. Slickdeals built a community-driven variant where users vote deals to the front page. These are reported public figures; they are context, not our design targets.

For capacity planning, this answer explicitly assumes a mature platform with 40 million registered users, 5 million daily active users, 80,000 tracked merchants, 2.5 million active offers, 40 affiliate network and direct partner feeds, and a 10x Black Friday peak. Unless a number is tied to a named public report, it is a stated design assumption.

The four architectural planes

1. Ingestion plane: feed connectors, schema mapping, normalization, deduplication, source reputation, and offer upserts.
2. Catalog and discovery plane: offer store, search index, merchant pages, category taxonomy, and read caching.
3. Engagement and attribution plane: outbound click redirect, sub-ID tracking, conversion postbacks, user code reports, and commission reconciliation.
4. Validation and quality plane: success-rate scoring, freshness decay, probe scheduling, takedown and revival workflows.

A strong interview answer keeps these planes separate. Ingestion failures must not block search, attribution must not depend on search availability, and a validation downgrade must degrade ranking quality before it degrades correctness.