Design the backend for a food-delivery product (think DoorDash-style marketplace). The system has two distinct surfaces that you must address together: 1. **A customer-facing food-item detail page.** Each food item shows an aggregated rating on a 5-point scale and a feed of user-generated posts attached to that item. Users can like posts. 2. **A monthly driver settlement system.** At the end of each calendar month, the system must calculate and settle each driver's earnings based on their completed deliveries, and pay them out. The interesting tension in this problem is that these two surfaces have very different requirements: the item page is read-heavy and tolerant of slightly stale data, while driver payouts are money-movement that must be correct, auditable, and exactly-once. Your design should cover functional requirements, APIs, the data model, storage choices, service decomposition, the rating-aggregation strategy, post/like handling, the month-end payout pipeline, the consistency requirements of each surface, and how the system scales. ### Constraints & Assumptions - Assume a large marketplace: on the order of tens of millions of food items, hundreds of millions of posts, and a heavy read:write skew on the item page (reads dominate writes by 100:1 or more). Treat exact numbers as something to confirm with the interviewer; the orders of magnitude drive the design. - Item-page reads should be low-latency (tens of milliseconds) and highly available. A few seconds of staleness on a rating average or like count is acceptable. - A user may rate a given item at most once; re-rating updates their existing score. A user may like a given post at most once. - Driver payouts run once per calendar month, after a cutoff, and must be reproducible from historical data. A payment to an external processor must never be duplicated, even across retries and re-runs. - An external payment processor exists and is the system of record for money actually leaving your account; you call it via an API and it is the integration point that can fail, time out, or return ambiguously. ### Clarifying Questions to Ask - Can a user rate the same item multiple times, or is it one mutable rating per user? Does an edit re-weight the average? - Are posts moderated, and do they need to support edits/deletes that must remove the post (and its likes) from the feed and counts? - What is the SLA on the item page, and how fresh must the rating average and like counts be (real-time vs. seconds vs. minutes)? - What exactly composes driver earnings — base pay, distance/time pay, tips, bonuses, penalties, prior-month adjustments? Who is the source of truth for each component? - What is the payment cutoff and timezone for "end of month," and how are late-arriving deliveries or tip adjustments that land after cutoff handled? - What are the regulatory/audit requirements on payouts (immutability, retention, reconciliation reporting)? ### Part 1 — Item detail page: ratings, posts, and likes (the read-heavy surface) Design the read and write path for the food-item detail page. Cover how a rating is submitted and how the 5-point aggregate is maintained; how posts are stored and paginated under an item; and how likes are recorded and counted. Specify the data model, the APIs, where you cache, and what consistency you offer for each piece (aggregate average, post feed, like count, and the uniqueness of a user's rating/like). ```hint Where to start Separate the **write of a raw event** (one rating, one like) from the **read of an aggregate** (average score, like count). The aggregate is precomputed and cached; the page should never recompute an average by scanning all ratings on demand. ``` ```hint Maintaining the average incrementally Store `total_score` and `rating_count` per item, not a list. Then $\text{avg} = \text{total\_score} / \text{rating\_count}$. When a user edits a rating from $s_\text{old}$ to $s_\text{new}$, apply a delta of $(s_\text{new} - s_\text{old})$ to `total_score` and leave `rating_count` unchanged — so you need the user's previous score, which means a per-(user,item) rating row. ``` ```hint Likes at scale A unique constraint on `(post_id, user_id)` enforces "one like per user" strongly even while the displayed **count** is updated asynchronously. Hot posts create counter contention — think about sharded counters or async increments rather than a single row everyone updates. ``` #### What This Part Should Cover - A clean split between an immutable event/record (rating row, like row) and a precomputed aggregate (avg/count) that serves reads. - Correct incremental aggregate maintenance, including the edit/re-rate and unlike cases (deltas, not recomputation). - Strong uniqueness for a user's rating and like, paired with eventually-consistent counts — and an explicit statement of what staleness is acceptable where. - Pagination of the post feed (cursor on `created_at`/id, not offset) and a caching strategy for hot item pages and counts. ### Part 2 — Month-end driver settlement and payout (the money-movement surface) Design the pipeline that, at month end, computes each driver's earnings from their completed deliveries and pays them out via an external payment processor. Cover how per-delivery earnings are recorded during the month, how the month-end run aggregates them, and how you guarantee each driver is paid the correct amount exactly once despite retries, partial failures, and re-runs. ```hint Build the ledger continuously, settle in batch Don't compute earnings from scratch at month end. As each delivery completes, append **immutable ledger entries** (base, tips, bonus, penalty, adjustment). The month-end job aggregates an append-only ledger — it never mutates balances — so any payout is reproducible from history. ``` ```hint Exactly-once payout Idempotency is the crux. Give each driver-month payout a deterministic **idempotency key** (e.g. `driver_id:YYYY-MM`) and pass it to the payment processor so a retried call is recognized and not double-charged. Persist payout state (`pending → submitted → succeeded/failed`) so the run is resumable and a re-run skips already-succeeded payouts. ``` ```hint Late and corrective data A tip or adjustment that arrives after cutoff should not rewrite a settled run. Prefer appending a **corrective ledger entry** that rolls into the next month's run (or a controlled re-run that issues only the delta), so settled history stays immutable. ``` #### Clarifying Questions for this Part - Is the external payment processor itself idempotent (does it accept and honor an idempotency key), or must you build exactly-once entirely on your side? - If a payout's status is ambiguous after a timeout (submitted but no confirmation), what is the policy — reconcile-then-retry, or block and alert? #### What This Part Should Cover - An append-only ledger as the source of truth for earnings, with per-delivery entries created during the month (not at cutoff). - A settlement run modeled as a stateful, resumable, checkpointed job with a clear per-driver payout state machine. - Exactly-once payment: a deterministic idempotency key end-to-end, retry safety, and re-run safety (already-succeeded payouts are skipped). - A defensible policy for late-arriving / corrective amounts that preserves the immutability of a settled run. ### What a Strong Answer Covers Across both parts, the strongest answers make the consistency contrast explicit and let it drive the architecture rather than treating the two surfaces uniformly: - A clear statement that the read surface (Part 1) is eventually consistent and optimized for read latency/availability, while the money surface (Part 2) is strongly consistent, auditable, and exactly-once — and a design that physically separates these paths (separate services, stores, and failure domains). - A coherent data model and service decomposition spanning both surfaces, with sensible storage choices (relational for ledger/payouts and uniqueness constraints; cache for hot reads; an event bus/queue for async aggregation). - Concrete failure handling: aggregation worker downtime (replay events), stale counters (self-healing), and payment-processor failures (idempotent retry, reconciliation). - Observability that proves correctness where it matters: page latency / cache-hit rate / aggregation lag on the read side, and settlement-run duration, failed-payout count, and ledger-vs-payout reconciliation on the money side. ### Follow-up Questions - A reconciliation job finds the sum of `total_score` across rating rows disagrees with the cached aggregate for some items. How did this drift happen, and how do you detect and repair it without taking the page down? - The payment processor returns success for a payout, but your service crashes before persisting that result; the next run sees the payout as still `submitted`. Walk through exactly how you avoid double-paying this driver. - Tips for completed deliveries can be edited by customers for up to a week after the order. How does this change your month-end cutoff strategy and your ledger/correction model? - Suppose product wants the rating average to reflect a new rating "instantly" on the rater's own next page load, even though it's eventually consistent for everyone else. How would you achieve that read-your-own-writes guarantee cheaply?