CrackML by @ml.with.umang
Interview questions / ML System Design
ML System Design interview question

Design a Sales-Based Ranking Data Structure

Design a service/data structure that maintains item rankings as sales counts update continuously.

mediumsystem designEvidence 66/1001 source reportAmazon

The 60-second answer

Clarify operations and consistency: point updates, top-K queries, rank-of-item, time windows, ties, and expected read/write volume. For a single process, combine a key→score map with an ordered structure/heap depending required operations; for windows, account for expiration/decrements.

Build the answer in this order

1
Frame the problem

Clarify operations and consistency: point updates, top-K queries, rank-of-item, time windows, ties, and expected read/write volume.

2
Design the data path

For a single process, combine a key→score map with an ordered structure/heap depending required operations; for windows, account for expiration/decrements.

3
Choose the modeling stack

At scale, shard updates, aggregate counters, and maintain approximate or materialized top-K views with clear staleness bounds.

4
Serve, evaluate, iterate

Test tie semantics, duplicate updates, late events, rank churn, and recovery from missed/replayed events.

A useful interview mental model

This is the shape of a strong answer—not a script to memorize.

01Requirements
02Data
03Model / Retrieval
04Serving
05Monitor

Senior-level signal

  • Senior answers choose exact vs approximate ranking from product tolerance and scale.
  • Discuss event idempotency, time-window semantics, and how hot items affect partitioning.

What the interviewer is really testing

Product framing, data design, modeling choices, serving constraints, reliability, evaluation, and explicit trade-offs.

Likely follow-up questions

What changes at 10× traffic or data volume?
Which failure mode would you monitor first in production?
How would you evaluate this offline and online before rollout?

Common weak-answer patterns

  • Jumping to a model before defining the product contract.
  • Listing components without bottlenecks, metrics, or failure handling.
  • Ignoring data quality, serving latency, monitoring, and iteration.