Think of Amazon’s review system as a municipal water treatment plant. Raw water - reviews - flows in from thousands of sources simultaneously. Some of it is perfectly clean. Some carries sediment you can filter mechanically - duplicate submissions that arrive twice because a mobile app retried on a flaky connection. Some carries chemical contaminants - fake reviews planted by sellers or review farms - that require a completely different detection mechanism. And the plant must deliver clean, drinkable water to 300 million customers in real time, not hours later. The treatment pipeline does not operate on water in batch mode once per day. It processes continuously, taps multiple filtration stages in sequence, and maintains rolling quality measurements across every product in a catalogue of 400 million items.

The numbers make this hard in very specific ways. Amazon processes roughly 2.5 million new reviews per day across its global marketplace - that is about 30 submissions per second at average load, spiking to over 500 per second during Prime Day or holiday shopping events. Each review carries not just text and a star rating but a behavioral context: when the user purchased the item, how many reviews that account has written in the last 30 days, whether the purchase was verified, and dozens of other signals. Storing that raw event is the easy part. The hard part is doing six things simultaneously: detecting duplicates before they inflate counts, scoring fraud risk within the same request window, updating a product’s rolling average atomically, re-ranking the “most helpful” list, keeping the search index fresh, and serving all of this to product detail pages that see 10,000 reads per second for a bestselling ASIN.

A naive approach - write review to Postgres, recompute the average via SELECT AVG(rating), and sort by helpful_votes DESC - breaks at scale for three distinct reasons. First, a full-table scan over 50 million reviews for a popular product just to recompute one average kills your database during every write. Second, duplicate detection via a UNIQUE constraint on (user_id, product_id) misses the case where a review farm submits 500 slightly different reviews from 500 different compromised accounts all rating the same ASIN. Third, a simple ORDER BY helpful_votes DESC ranking is trivially gameable: a single viral review from a week ago will always outrank a newer one that is objectively more useful. You need a confidence-adjusted score, not a raw vote count.

We need to solve for throughput isolation - writes must not block reads, and fraud scoring must not block writes - plus incrementally maintained aggregates instead of recomputed ones, plus a statistically robust ranking function, all simultaneously.

Requirements and Constraints

Functional Requirements

• Accept review submissions (star rating 1-5, free text up to 5,000 chars, optional media) and return an acknowledgement within 200ms
• Deduplicate submissions: reject exact duplicates within 90 days and near-duplicates from the same account on the same product within 24 hours
• Score each review for fraud using behavioral signals; reject high-confidence fraud, queue borderline cases for human review
• Maintain per-product rolling average star rating that updates within 5 seconds of a new verified review landing
• Rank visible reviews per product by “helpfulness,” defined as a Wilson score lower confidence bound on the helpful-vote ratio
• Surface the top-50 reviews per product on the product detail page (sorted by helpfulness, then recency)
• Allow full-text search of reviews per product with faceting by star rating, verified purchase, and recency
• Support soft-deletion of reviews that are later flagged by moderators, with all aggregates updated accordingly

Non-Functional Requirements

• Write throughput: 500 submissions/second sustained, 2,000/second burst (10x Prime Day spike)
• Read throughput: 50,000 requests/second for product review pages (read-heavy ratio 100:1)
• Review aggregate latency: average star rating visible to 99% of users within 5 seconds of a new review passing fraud check
• API p99 write latency: under 250ms (synchronous dedup check + Kafka publish)
• API p99 read latency: under 50ms for cached product review summaries
• Fraud detection latency: under 500ms per review in the async scoring pipeline
• Durability: zero review data loss; all raw submissions retained in S3 for 7 years (regulatory)
• Availability: 99.99% uptime on read path; writes can degrade gracefully to async-only mode
• Storage: approximately 5 TB for 3 years of review text + metadata; 200 GB for Redis working set

Constraints and Assumptions

• Reviews are not editable after submission (simplifies aggregate maintenance)
• Helpful votes are a separate event stream, not part of the review submission pipeline
• We do not build the ML training pipeline here - the fraud model is pre-trained and served via a feature store
• Geographic distribution (per-country review sets) is out of scope; we design for a single region
• Comment/reply threads on reviews are out of scope

High-Level Architecture

The system separates into five major components with distinct scaling characteristics. Understanding which component dominates which bottleneck is the key to sizing the system correctly.

The Review API Gateway handles inbound submissions, enforces rate limits (10 reviews/user/day), authenticates the request via the customer identity service, and performs the synchronous deduplication check. It returns a 202 Accepted to the customer immediately after publishing to Kafka - the rest of the pipeline is asynchronous.

The Dedup Service runs inside the API gateway request path. It computes a fingerprint from (asin, user_id, normalized_text) and checks Redis for that fingerprint using SETNX. If the key already exists, the submission is rejected with a 409 Conflict. This is the only part of the pipeline that blocks the customer’s HTTP request.

The Fraud Detection Service consumes the review-submissions Kafka topic, extracts behavioral signals, scores via a pre-loaded XGBoost model, and routes: clean reviews pass to the rating aggregator, high-confidence fraud is dropped with a moderation record, and borderline cases go to a human review queue backed by DynamoDB.

The Rating Aggregator maintains (weighted_sum, count) per ASIN using Redis HINCRBYFLOAT and HINCRBY, computing the live average as weighted_sum / count. It also writes the updated aggregate to PostgreSQL for durability. This component handles the hot-path throughput problem by avoiding any read-modify-write cycle.

The Review Index is an Elasticsearch cluster that maintains a document per review with analyzed text, structured facets, and a helpfulness_score field that drives the sort. Elasticsearch’s update_by_query is too slow for real-time updates; instead, each vote event triggers a targeted _update on the specific review document.

The Deduplication Stage

The deduplication job is to answer a single question before the customer’s HTTP connection closes: “have we seen this review before?” Like a postal sorter checking return addresses against a bounce list, it must do this check in under 10 milliseconds for the write latency budget to work out.