At Meesho, reviews are one of the strongest drivers of trust. They influence not just what users buy, but how sellers build reputation and how product quality is interpreted relative to price.

But building a review system at scale quickly stops being a UI problem. It becomes a distributed systems problem: handling review writes at scale, read-heavy workloads, processing user-generated media, extracting insights from unstructured feedback, and maintaining trust in the presence of abuse.

Complicating things further, Meesho serves a very diverse user base. Some users browse on high-end smartphones in Tier-1 cities with fast networks, while others browse from Tier-2 and Tier-3 towns on entry-level Android devices with intermittent connectivity.

The review platform must work equally well for both.

Over time, the system evolved from a simple ratings service into an event-driven architecture built around a simple principle: One source of truth, many derived views.

This is the first blog in a series on how we built and scaled the Meesho review platform. This particular blog covers the architectural foundations - how reviews are written, processed, and consumed.

This evolution can be understood through three journeys:

  • The Existing Customer - writing the review
  • The Platform - processing and scaling reviews
  • The Potential Buyer - consuming reviews efficiently

Each of these journeys led to a different set of architectural choices.

Part 1: Existing Customers

Designing for Fast and Reliable Review Submissions

For an existing customer who has already purchased a product, leaving a review should feel instantaneous. The interaction typically happens shortly after delivery when the experience is fresh.

However, behind the scenes a single review submission can trigger multiple processes:

  • Persistence
  • Rating aggregation
  • Media processing
  • Fraud detection
  • Moderation
  • Analytics pipelines

Executing all of these synchronously would significantly increase latency and tightly couple multiple systems. Instead, the system isolates the transactional boundary to a single database write.

Architecture Diagram – Review Write Path

The Write Path

The review service follows a straightforward but deliberate flow:

API → Manager → DAO → MongoDB

The service uses a DAO layer for persistence. When an existing customer submits a review:

  1. The API validates the request.
  2. The request is passed to manager classes (such as CreateReviewManager).
  3. Managers use DAO classes to persist review entities and associated metadata.

MongoDB acts as the transactional source of truth.

The system stores review metadata, ratings, comments, and references to media files in MongoDB. The actual image or video files are stored separately in object storage, and the review service stores only URLs pointing to those assets.

Once the database write succeeds, the service publishes review lifecycle events to Kafka. These events trigger downstream consumers responsible for:

  • Updating aggregates
  • Running moderation pipelines
  • Performing analytics
  • Feeding intelligence pipelines

The key idea is that the write path stops after persistence and event publication. Everything else runs asynchronously.

Handling Media Without Breaking the Experience

Images and videos dramatically improve the credibility of reviews. They allow potential buyers to see the product in real-world conditions - often revealing details that studio images or catalog photos might miss. In many cases, user-generated media provides the most unbiased view of what will actually arrive, helping buyers assess factors such as fabric quality, colour accuracy, fit, or build quality.

However, Media also introduces heavy payloads and resource-intensive processing steps. Uploading and processing large images or videos directly through the review API would increase request sizes, cause timeouts on slower networks, and significantly slow down the review submission flow.

Why Media in the Submission Path Hurts

Uploading and processing media inside the review submission path would significantly increase latency and degrade experience in several ways:

  1. Upload time – Large payloads take longer to transfer, especially on slow networks.
  2. Processing time – Resizing or transcoding media is CPU- and I/O-intensive.
  3. Coupling and failure – Media pipeline failures would block review submission.Timeouts and retries – Long operations cause gateway timeouts and retries.

The system therefore follows an Upload–Notify architecture. Users upload images and videos directly to object storage. The review service stores only metadata and references in the database (for example, image or video URLs and status). The same data is later propagated to read models such as MongoDB by event consumers.

No large blobs flow through the review API. Once the review is committed, asynchronous workers process the media pipeline.

Architecture Diagram – UGC Media Pipeline

Designing for Device and Network Diversity

A critical design consideration is the diversity of devices and networks. A prospective buyer browsing from a high-end smartphone in a Tier-1 city may load large images quickly. A buyer using a low-end Android phone in a Tier-3 town may struggle with the same content.

Serving large uncompressed images would significantly slow down page rendering for many users. To address this, the platform optimizes user-generated content at multiple levels.

Pixius

An internal service handles image optimization and generates multiple compressed variants so that the system can serve the following variants depending on the context:

  • Thumbnails
  • Medium & Full resolution images

Media Orchestrator

Coordinates thumbnail generation and upload flows for both images and videos. For video reviews it generates thumbnails and normalised streaming URLs.

CDN Layer

Further optimizes delivery by:

  • Resizing assets on the fly
  • Selecting device-appropriate formats

This ensures the same asset can be served efficiently across different network conditions and screen sizes.

Voice Reviews and Alternative Input Methods

Typing long reviews can be difficult for users who are more comfortable speaking than typing- for example those who prefer vernacular languages, are new to e-commerce, or are less practiced at long-form text entry on a phone. For them, dictating feedback is often faster than pecking out a paragraph, even though the path involves microphone use and speech recognition (often assisted by the OS or network) rather than the lighter local cost of keystrokes.

To reduce this friction, the review flow supports voice-to-text review input directly on the client.

Instead of routing raw audio through backend services, the application relies on the device’s native speech recognition capabilities. On Android devices, this is implemented using the platform’s built-in APIs:

  • android.speech.SpeechRecognizer
  • android.speech.RecognizerIntent

The recognized text is then passed back to the review screen and treated exactly like typed input before being submitted to the review service.

This design ensures that the backend review infrastructure does not need to differentiate between typed reviews and voice-generated reviews. Both ultimately enter the system as normalised text.

The recognized text is then passed back to the review screen and treated exactly like typed input before being submitted to the review service.

This design ensures that the backend review infrastructure does not need to differentiate between typed reviews and voice-generated reviews. Both ultimately enter the system as normalized text.

Part 2: The Platform

The review platform separates truth, serving, and interpretation layers, with each datastore playing a specific role. This keeps the write path simple while allowing downstream systems to scale independently.

MongoDB - Source of Truth

MongoDB stores the primary transactional record for reviews, including:

  • Review Metadata
  • Ratings
  • Comments
  • Media References

All review submissions are written directly to MongoDB.

Because the review document already contains most of the information required to render a review, MongoDB also serves as the primary store for review listings and product page queries.

Aggregate frequency tables such as product and catalog rating distributions are updated incrementally by Kafka consumers based on review lifecycle events.

Apache DragonFly - Read Cache

Apache DragonFly acts as a read-through cache for frequently accessed review aggregates.

On a cache miss, the API fetches the required data from MongoDB and stores the response in Apache DragonFly to speed up future requests.

Kafka - Event Backbone

Kafka serves as the central event backbone of the review platform.

Review lifecycle events propagate through Kafka and drive downstream pipelines such as:

  • aggregate updates
  • moderation pipelines
  • ML enrichment
  • analytics processing

Because these systems consume events asynchronously, they can evolve independently without affecting the core review service.

Part 3: Potential Buyers

Review Synthesis via LLMs

Why Structured Topic Extraction

Free-text summaries are difficult to aggregate at catalog scale. Instead, the pipeline converts multilingual review text into structured records aligned to a fixed schema.

Each processed review produces fields such as:

  • L1 / L2 taxonomy labels
  • Sentiment polarity
  • Verbatim clause span
  • Attribute type (product vs logistics)
  • Confidence score

This schema allows downstream systems to aggregate, index, and analyze reviews using standard queries without re-running LLM inference.

In practice, the system treats review synthesis as an information extraction problem, not a summarisation task.

Execution Model

LLM inference runs asynchronously outside the API request path. A Kafka-driven consumer processes review LLM input events containing the review text and catalog context. The handler constructs prompts, invokes the LLM client, parses structured output, and publishes results to downstream stores such as Kafka or analytics tables (e.g., Presto).

This keeps review writes and reads unaffected by model latency.

Prompt and Extraction Design

Inference uses chat-style prompts assembled by LLMService, combining:

  • a system prompt containing extraction rules
  • few-shot examples for edge cases
  • the current review text

The prompt injects a taxonomy of allowed labels (L1/L2) based on product category. Constraining the label space reduces topic drift and keeps outputs consistent across reviews.

The model is instructed to produce structured JSON output containing extracted topics, sentiment, and confidence values.

Low temperature settings are typically used to reduce generative variation for extraction tasks.

Reliability and Guardrails

To reduce hallucinations and ensure operational safety:

  • Prompts require outputs to be grounded in the review text
  • Topic labels are restricted to taxonomy-defined values
  • Outputs undergo schema validation before persistence
  • Processing is idempotent by review_id, allowing safe retries

Downstream systems can also use confidence scores for filtering or QA sampling.

Denormalized Read Models

Serving reviews efficiently requires flexible filtering and sorting. Relational queries across multiple tables do not scale well for read-heavy workloads. Instead, the platform maintains denormalized review documents in MongoDB..

These documents include:

  • Review identifiers and product context
  • Rating and comment text
  • Media references
  • Helpful vote counts
  • Fraud indicators
  • Synthesis outputs

A Kafka consumer (CRUDMongoConsumer) listens to review lifecycle topics. On create or update events:

  1. The CreateEventHandler constructs or updates the review document.
  2. The document is written to MongoDB.
  3. The same event can also trigger Elasticsearch indexing.

This ensures that the API writes data only once, while downstream consumers maintain the read model asynchronously.

Review Media Consumption

Many potential buyers do not stop at thumbnails. They often open images in full screen and pinch-zoom into review photos to judge details such as fabric texture, weave, true colour, stitching, or packaging-information that is difficult to infer from catalog images alone.

Review videos are increasingly important for the same reason. Motion, lighting changes, and real-world handling can make products feel more authentic than a single frame. In several categories, video can be especially useful in some categories..

Supporting this behaviour at scale requires careful media delivery design.

Handling Image Zoom Efficiently

Users frequently zoom into review images to inspect fine details. This requires high-resolution images, but serving large images by default would significantly increase page load times and bandwidth usage.

The platform therefore follows a tiered image delivery strategy.

  • Smaller variants are used for carousels and review grids so that scrolling remains fast.
  • When a user opens the image viewer or performs a zoom gesture, the client requests a higher-resolution variant.

These higher-resolution versions may come from:

  • pre-generated image variants created during the media processing pipeline
  • CDN resize-on-demand, where the CDN dynamically serves an appropriate size

The review read model only stores stable references to the asset. Which resolution is loaded becomes a client + CDN responsibility, not a database concern.

Intent-Based Media Loading

High-resolution images are expensive not only in bandwidth but also in decode memory on low-end devices. Very large bitmaps can introduce rendering delays or even cause memory pressure on entry-level phones.

To address this, the system follows an intent-based loading model.

Large image variants are only fetched when user behaviour signals intent:

  • opening the image viewer
  • zooming into the photo

This ensures:

  • fast initial page loads
  • reduced network usage
  • smoother performance on low-RAM devices

Review Ranking and Relevance

Not all reviews are equally useful to a prospective buyer. To improve relevance, the platform computes a composite ranking score for each review based on multiple signals:

  • rating deviation from product median
  • review text richness
  • presence of images
  • helpful vote counts
  • recency

This score determines the default ordering of reviews.

Closing Thoughts

Building reviews at scale required balancing three competing goals:

  • Enabling existing customers to express feedback easily
  • Helping prospective buyers interpret that feedback quickly
  • Ensuring the platform could scale safely

By keeping the write path small, separating media pipelines, and layering intelligence systems such as LLM-driven review synthesis on top of a stable architecture, the review system continues to evolve without sacrificing performance or trust.

When a system separates truth from interpretation, new capabilities-from summarised feedback to seller quality analysis-can be added without changing the foundations.

What's Next in This Series

This blog covered the foundations - how reviews are written, processed, and served at scale. But there's a lot more under the hood.

In the upcoming posts, we'll go deeper into:

  • Review Synthesis - how we use LLM pipelines to turn thousands of individual reviews into meaningful, summarised feedback
  • Trust & Moderation - how ML-based pipelines detect and filter abuse at scale
  • Read Models & Ranking - how we keep our read layer fast and relevant as data grows
  • Scale & Operations - RPS distribution, consumer flows, and how we manage it all at the infrastructure level

Stay tuned - each of these is a rabbit hole worth going down.

Special thanks to Kunal Kariwala for his contributions and collaboration on this work.