Design a product likes system for a marketplace of brands and retailers

Design the backend for product likes on a marketplace where brands list products and retailers browse them. The system must support four features: 1. A retailer can like or dislike a product. 2. A retailer can see the products they have liked. 3. When a retailer searches, each product in the search results shows its likes. 4. A brand can see the likes on each of its products. ```hint Two very different read paths Listing one retailer's liked products and counting the likes on one product read the same facts in opposite directions. Decide what each path reads, and whether one table with the right indexes can serve both. ``` ```hint A results page asks about many products at once A search page needs like information for dozens of products in a single request. Think about where those numbers live so that rendering a page never counts rows on the fly, and how fresh they really need to be. ``` ### Constraints and Clarifications - Not given: the number of retailers, brands and products, like traffic, search traffic, and how fresh the counts must be. Ask, or state your assumptions. - The source does not say whether "dislike" undoes a like or is a separate negative reaction. Settle it with the interviewer. ### Clarifying Questions - Does "dislike" mean removing a like, or a separate negative reaction that is stored and counted? Can a retailer hold a like and a dislike on the same product at once? - In search results, does a retailer see only the like count, or also whether they themselves have liked each product? - Does a brand see only counts, or also which retailers liked each product, and over what time period? - Must counts be exact and update instantly, or may they lag by a few seconds? - In what order are a retailer's liked products listed, and how long can that list get? - What happens to likes when a product is removed or a retailer closes their account? ### What a Strong Answer Covers - Settles the meaning of dislike, what each audience sees, and the freshness requirement before designing - A data model with one source of truth per retailer and product, a uniqueness rule that makes repeated likes harmless, and indexes for both the per-retailer and per-product directions - APIs for reacting, a paginated list of a retailer's liked products, batched like information for a results page, and the brand view - A counting strategy for search results: where counts are stored, how they are updated, how they reach the search response, and how drift is repaired - Brand-side visibility and privacy, sizing estimates, scaling, failure handling and monitoring ### Follow-up Questions - A popular product receives a sudden burst of likes. How do you keep its counter from becoming a write hotspot? - Retailers want to sort search results by number of likes. What changes, given that the search index now depends on counts? - A brand asks for likes over time, broken down by type of retailer. Do you query the main store, or build something else? - After an outage, the counters and the reaction records disagree. How do you detect and repair the drift?