Design a Real-Time Leaderboard and Counting Service

The ad-click system taught Rafael to count exactly. When money rides on a number, you dedupe, you reconcile, you never trust the stream alone. So when the growth team asks for a live flash-sale leaderboard - top-selling products and top buyers, updating on the big screen as orders pour in - his instinct is to reach for the same exactness. Then he looks at what the board actually is, and realizes the lesson this time is the opposite one.

The naive build is a counter per product in a database, incremented on every order, and a query for the board: SELECT product, count FROM sales GROUP BY product ORDER BY count DESC LIMIT 100. During a normal week it's fine. During the flash sale, fifty thousand orders a second slam the write path, and every one of a million shoppers refreshing the page fires that ORDER BY over millions of products. The database sorts the whole catalog, hundreds of times a second, and falls over. And that's just the ranked board - the growth team also wants "unique buyers per product," which, done exactly, means holding a set of buyer ids for every product: gigabytes of state that grows without bound.

The tension that shapes the design, and the inversion of the billing lesson: the leaderboard is a display, not an invoice. Nobody audits whether the seventh-place product was truly seventh or actually eighth. "Roughly right, right now" beats "exactly right, a minute late." That single realization unlocks a family of tiny, fast, approximate data structures - and the whole skill of this problem is knowing precisely when you're allowed to use them, and when, like the invoice, you are not.

Step 1 - Understand the Problem and Establish Design Scope

"Build a leaderboard" hides the question that decides everything: how exact does the output have to be? The clarifying questions get there fast.

Candidate: What's on the board, and how many boards?

Interviewer: Two. Top-selling products, ranked by units sold during the sale, and top buyers, ranked by total spend. Say the top 100 of each. It's a live hype feature for the flash sale.

Candidate: How live? How stale can a rank be?

Interviewer: It should visibly move. An order should affect the board within a second or two. That liveness is the whole point.

Candidate: How many products and buyers are we ranking over?

Interviewer: Millions of products in the catalog, a few hundred thousand active in the sale, and millions of buyers.

Candidate: Here's the one that changes the design. Does the board have to be exactly right? If the true tenth-place product shows up as eleventh for a few seconds, is that a bug?

Interviewer: No. It's a display. As long as the top of the board is right and it feels live, small errors in exact rank or count are completely fine. The reconciled sales numbers that finance and seller payouts use come from a different, exact pipeline.

Candidate: That's the unlock. It means I can use approximate structures where exact ones would cost far more. Let me confirm the read/write shape.

Interviewer: Reads dominate. Every shopper loads the board; far fewer place orders. And yes, we also want a couple of "unique buyers" counters - unique buyers per product and total unique buyers in the sale.

Candidate: Unique counts are the other place approximation earns its keep. Got it.

The design is decided by one answer: the output tolerates bounded error, so the state can be tiny.

Functional requirements

• Maintain and serve the top-K products (by units) and top-K buyers (by spend), updated live during the sale.
• Serve the current rank and score of a specific product or buyer on request.
• Track approximate distinct counts: unique buyers per product, and total unique buyers.
• Survive a crash and restore the board without leaving it permanently wrong.