Section 12: Two Problems, One Verdict - Final Summary & Candidate Scorecard
Executive Summary: This closing section turns the module into a grading instrument. We replay the interview section by section and name the signal each phase was recording, then give a 100-point scorecard weighted toward architecture and deep-dive depth, because this problem is won or lost on semantics, not volume. Each dimension says what a top score sounds like for ClipKart specifically and where points leak. Score bands map to readiness levels with targeted remediation, and a final catalog shows where the same "head versus whole order" question hides in other loops.
Remember what the interviewer said at minute one: a button for the Top 10 in the last 1, 4 or 24 hours, and a rank for every product in every category. Everything after that was the interviewer watching for one moment, the moment you noticed those are two different problems. The candidate who notices early spends the rest of the hour building two small, exact machines. The one who doesn't spends it defending a single machine that can't say "#1,056" or can't say "last 1 hour." The scorecard below is mostly a record of when, and how convincingly, that moment happened.
The Arc, Replayed as Signal
| Section | What you did | Signal the interviewer recorded |
|---|---|---|
| 1. Problem Understanding | Split the prompt into a minutes-fresh head and an hourly full order; asked what "most bought" means | Decomposition before machinery; didn't recite heap + Count-Min Sketch on reflex |
| 2. Requirements | Wrote ≤ 2 min p99 Top-10 freshness, ≤ 75 min rank freshness, exact counts, unique ranks | NFRs a test could verify, with a different freshness per feature |
| 3. Scale Estimation | Derived 694/s average → 15,000 events/s design peak, ~5.6 GB of state, a 5.8 GB hourly sort | Arithmetic that changed decisions: exact counting is affordable |
| 4. API Design | Three read shapes (four endpoints), enum windows, asOf everywhere, no write API, no public unit counts |
A small surface and the confidence to refuse requests |
| 5. Data Modeling | Access patterns first; minute buckets, closure table, versioned rank:v{N} keys |
Storage chosen for its access pattern, not out of habit |
| 6. Architecture | Outbox + CDC → Kafka keyed by productId → speed path and rank path | Two pipelines justified by the two shapes; every absence defended |
| 7. Sliding-Window Top-10 | "11th everywhere, 1st globally"; subtract the leaving minute; cancellations hit the original minute | Correctness reasoning at the mechanism level, not "Flink handles it" |
| 8. Every Product's Rank | Decayed score ×0.97153 per hour, row_number with a tiebreak, write the next version, then flip | Consistency and fairness under a full sort of 240M rows |
| 9. Challenges | Hot key at 1,667 events/s, ~72,000 units of sketch overcount, "why real-time?" | Composure; answering escalations with numbers and flip triggers |
| 10. Reliability & Integrity | Stale-with-asOf degradation ladder; buyer cap of 5, fraud retractions, velocity holds |
Thinking like an operator and like an adversarial seller |
| 11. Evolution | Per-city lists, Movers & Shakers from snapshot history in the lake, per-segment lists | A design that absorbs new features without being rebuilt |
Key Insight: Most of these rows record the same habit at different depths: matching each mechanism to the shape of its question. The Top-10 needs 10 items per list, so it gets a heavy-hitters pipeline. The rank needs the entire order, so it gets a sort. Every strong answer in this module came from keeping those two apart.
Quick check before moving on:
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson