Coupons and Deals Platform

01What do users do here — scroll a feed, search, or both?

Both: users browse and search a large, frequently changing deal catalog by category, location, and merchant — and every one of those requests is served from cache or index, never the primary database.

02A coupon has 100 uses — what is the hard rule?

It redeems exactly 100 times, ever: the global limit is enforced by an atomic conditional decrement in the datastore, so the 101st attempt fails no matter how the requests race.

03Can one user redeem the same coupon twice?

No: a per-user limit (usually one) is enforced by a unique (user_id, coupon_id) redemption record — five devices tapping at once still produce exactly one redemption.

04A merchant cuts a price — how fast must users see it?

Within seconds: every merchant write publishes a cache-invalidation event, with the TTL as backstop — because a user redeeming at yesterday’s price is a merchant dispute.

05A deal expires while a user is looking at it — what wins?

Expiry wins: redemption revalidates expires_at inside the transaction, so a deal that search still shows as live cannot be redeemed after it ends.

06A merchant disputes a redemption — what can we show them?

An append-only audit trail: who redeemed which coupon, when, from which request — every redemption is a permanent record, never an update in place.

01What is the read-write shape of this system?

Read-heavy by hundreds to one: browsing never touches the primary database per request — it is served from cache and a search index sized for the read side alone.

02During a rush, may a 100-use coupon slip to 101?

Never: the global and per-user limits are hard invariants enforced atomically in the datastore — over-redeeming is a correctness bug, not a tolerance.

03How stale may a browsed deal be?

Seconds after a merchant edit with active invalidation, minutes at worst on the TTL backstop — and redemption always revalidates against the source of truth, so staleness can mislead but never transact.

04What latency does browse hold under a viral spike?

Browse holds roughly 100–200 ms p99 even when one viral deal concentrates the traffic, because hot keys are served from cache with stampede control, not from the database.

05The client times out mid-redeem and retries — what happens?

The retry carries the same idempotency key and gets the original outcome back — one tap, one redemption, no matter how many network retries happen in between.