This system design question evaluates a candidate's ability to architect a scalable review platform with voting, counter aggregation, and rewards at high traffic volumes. It tests practical knowledge of distributed counter strategies, idempotent write handling, read/write path separation, and abuse prevention — core competencies assessed in senior software engineer interviews.
Design a scalable review system for an e-commerce platform where customers can post reviews on products and upvote/downvote existing reviews, and review authors receive rewards based on upvote counts. Define APIs for creating reviews, voting, querying top reviews, and claiming rewards. Model the data schema for reviews, votes, and per-review upvote counters. Ensure idempotent voting, prevent double-votes and abuse (e.g., sybil/brigading), and support undo/changes. Propose a counter architecture (e.g., sharded or approximate counters) and a ranking strategy. Address scaling, caching, consistency, and reliability (failover, retries, deduplication), and outline monitoring and backfill processes.
Quick Answer: This system design question evaluates a candidate's ability to architect a scalable review platform with voting, counter aggregation, and rewards at high traffic volumes. It tests practical knowledge of distributed counter strategies, idempotent write handling, read/write path separation, and abuse prevention — core competencies assessed in senior software engineer interviews.
Design a Scalable Product Review System with Voting and Rewards
You are designing a reviews feature for a large e-commerce marketplace. Customers can post reviews on products, and other customers can upvote or downvote those reviews to signal helpfulness. Review authors earn rewards tied to how many upvotes their reviews accumulate. The system must scale to millions of products and heavy read/write traffic, stay reliable, and resist abuse.
Design the end-to-end system. Concretely, cover:
APIs
for: creating/editing/soft-deleting a review, voting (with undo and vote-change), querying top reviews per product (paginated, with filters such as
recent
,
top
, and
verified purchases
), and claiming rewards.
Data models
for reviews, votes, and the upvote/downvote counters (shards and/or aggregates).
Idempotent voting
with double-vote prevention and correct undo/change handling.
Counter architecture
(e.g., sharded or approximate counters) and a
ranking strategy
for "top reviews."
A
scaling, caching, consistency, and reliability
plan (failover, retries, deduplication).
Monitoring/metrics
and
backfill/repair
processes.
Constraints & Assumptions
State your own numbers, but a reasonable working set:
Scale:
~100M products (tens of millions reviewed), hundreds of millions of reviews total. ~100M DAU viewing product pages.
Traffic shape:
strongly
read-heavy
— top reviews render on essentially every product-page view (tens of thousands of reads/sec at peak), while votes and new reviews are orders of magnitude rarer but
concentrate on a small set of viral reviews / trending products
(the hot-key problem).
Latency:
low p99 on the "top reviews for a product" call; the vote write must be fast and durable.
Correctness:
idempotent voting and reward claiming; no double-votes; counters must be reconstructable from a durable source.
Identity:
a logged-in user identity is provided by an auth/gateway layer.
Out of scope (unless raised):
the product catalog, search, payment-processor internals (assume an existing wallet/payments service), and any personalization/recommendation model for reviews.
Clarifying Questions to Ask
How fresh must global upvote counts be on the read path — is seconds-level eventual consistency acceptable, or must counts be exact-on-read?
Are rewards monetary (cash/credit) or cosmetic? This sets how hard abuse prevention and claim-consistency need to be.
Should rewards be clawed back if upvotes are later removed or found fraudulent — and does the answer differ before vs. after a claim?
How are reward tiers defined (fixed thresholds on net upvotes? per-review caps?) and can a single review earn multiple tiers?
What is the abuse threat model we must defend against (sybil accounts, vote brigading, paid-vote rings, review spam) and what enforcement is acceptable (down-weighting vs. hard blocks)?
Single-region or multi-region? Cross-region
write
availability for votes/counters is a hard correctness driver.
What a Strong Answer Covers
Requirements & sizing:
separates functional vs. non-functional, does a back-of-the-envelope estimate, and uses the read:write ratio to justify a cached/precomputed read path and an event-driven write path.
APIs:
desired-state vote endpoint, idempotency keys on mutations,
cursor-based
(not offset) pagination, and a
my_vote
field that is per-user (not baked into a shared cached payload).
Data model:
reviews store, a vote source-of-truth keyed by
(review_id, voter_id)
(the double-vote guard), sharded counters, materialized aggregates, a precomputed top-K structure, and a rewards ledger with a uniqueness constraint.
Idempotent voting:
the correct transition/delta table (especially the
±2
up
↔
down swing), a conditional/compare-and-set write for concurrent submits, and a request-level idempotency mechanism for network retries — distinguished from stream-level event dedup.
Counters & ranking:
sharded counters with a justified shard-routing key, adaptive sharding for hot reviews, and a principled ranking score (Wilson lower bound + decay) kept fresh via an event-driven recompute; a concrete plan for pagination beyond the cached top-K.
Consistency & reliability:
a deliberately mixed consistency model (read-after-write for
my
vote, eventual for global counts, strong for reward claims), failover/quorum, graceful degradation when cache/stream is down, and at-least-once event handling with dedup.
Abuse prevention:
trust-weighted votes, rate limiting, risk scoring, brigading detection, content moderation/quarantine, and reward-fraud holds — treated as a primary requirement because rewards are money.
Observability & repair:
key metrics (latency, consumer lag, counter drift, claim success), and the ability to
reconstruct counters/ranking from the vote log
for backfill/repair.
Tradeoffs:
the candidate names and defends the big choices (sharded-exact vs. approximate counters; eventual vs. strong; desired-state vs. delta voting; Wilson+decay vs. ML; single-writer vs. CRDT multi-region).
Follow-up Questions
Walk through exactly what happens to votes, counters, ranking, and
already-earned rewards
when an author edits a review after it has accumulated upvotes. How do you stop the "earn upvotes on good content, then edit to spam" bait-and-switch without punishing a typo fix?
A single review goes viral and takes tens of thousands of votes per second. Trace the write through your system and show where it would hot-spot if you had
not
sharded — and how your shard-routing key behaves when the same user later changes or undoes their vote.
The cache (Redis) layer is completely down. What still works, what degrades, and what (if anything) returns wrong answers?
How would you run a multi-region deployment for counters — single-writer with async replication vs. per-region CRDT (PN-Counter)? What does each cost you in correctness and availability?