Marketplace Platform Low-Level Design: Listing Management, Search, and Trust and Safety

What Is a Marketplace Platform?

A marketplace platform connects buyers and sellers, managing the full lifecycle from product listing creation through search discovery, transaction, and post-sale dispute resolution. At the low-level design stage the challenge is coordinating a high write volume on listings and inventory with near-real-time search index freshness, while running trust and fraud signals without adding latency to the happy path. Every component must be independently scalable and the trust layer must operate asynchronously to avoid blocking purchases.

Requirements

Functional

Sellers can create, update, and delete listings with title, description, images, price, quantity, and category.
Buyers can search listings by keyword, category, price range, location, and seller trust score.
The platform computes a trust score for each buyer and seller based on transaction history, verification status, and behavioral signals.
Automated fraud prevention flags suspicious listings and transactions for review before money moves.
A dispute flow allows buyers to open a dispute within a defined window after delivery confirmation.

Non-Functional

Search P99 under 150 ms for queries returning up to 50 results.
Listing write throughput: 5 000 creates per minute sustained.
Fraud scoring must complete within 500 ms so it can gate checkout synchronously for high-risk transactions.

Data Model

Listing: listing_id, seller_id, title, description, price_cents, currency, quantity, category_id, status (DRAFT, ACTIVE, PAUSED, SOLD, REMOVED), condition, location_geohash, images[], created_at, updated_at.
Category: category_id, parent_id, name, slug, requires_shipping, fraud_risk_tier.
TrustScore: entity_id, entity_type (BUYER, SELLER), score (0-1000), components{}, last_computed_at, version.
FraudSignal: signal_id, entity_id, signal_type, severity (LOW, MEDIUM, HIGH), metadata_json, detected_at.
Dispute: dispute_id, order_id, buyer_id, seller_id, reason, status (OPEN, EVIDENCE_REQUESTED, UNDER_REVIEW, RESOLVED, ESCALATED), resolution (REFUND, PARTIAL_REFUND, DENIED, ESCALATED), opened_at, resolved_at.

Listings are stored in PostgreSQL. On every status change a Kafka event triggers the search indexer to upsert or delete the document in Elasticsearch. Trust scores are stored in PostgreSQL and cached in Redis with a 15-minute TTL.

Core Algorithms

Listing CRUD and Search Indexing

Listing writes go to PostgreSQL first. A transactional outbox table captures the change event in the same transaction, preventing partial failures where the database write succeeds but the Kafka publish fails. A change-data-capture (CDC) process reads the outbox and publishes events to Kafka. An indexing consumer reads events and upserts Elasticsearch documents including denormalized seller trust score and category metadata. Deletions set the document status field to REMOVED, allowing soft-delete queries rather than hard index deletions that could cause visibility gaps.

Trust Score Computation

Trust scores are computed by a scoring engine that aggregates multiple components: verification_score (identity, bank, phone each worth up to 100 points), transaction_score (completed orders, dispute rate, average rating), and behavioral_score (account age, login patterns, price deviation from category median). Components are weighted and summed to produce a 0-1000 integer. The engine runs on a schedule (every 15 minutes for active sellers with recent transactions, every 24 hours for dormant accounts) and on-demand when a significant event occurs (dispute opened, verification completed).

Fraud Prevention

At checkout, a synchronous fraud gate calls the fraud scoring service with the transaction amount, buyer_id, seller_id, and listing_id. The service applies a rule engine (price vs. category median deviation, velocity checks via Redis counters, buyer account age vs. transaction size) and returns a risk score with a PASS, REVIEW, or BLOCK decision in under 500 ms. REVIEW decisions queue the transaction for a human fraud analyst while holding funds in escrow. BLOCK decisions reject the transaction immediately. High-severity FraudSignal rows are written asynchronously after the gate decision to avoid adding latency.

Scalability and Reliability

Search scaling: Elasticsearch index sharded by category to allow category-specific relevance tuning and independent reindexing without global downtime.
Trust score caching: Redis cache with write-through on score update and TTL-based expiry keeps read latency under 5 ms for the fraud gate.
Listing fan-out: High-volume categories (electronics, fashion) get dedicated Kafka partitions so slow indexing in one category does not delay others.
Rate limiting on listing creation: New sellers are limited to 50 listings per hour via a Redis sliding window counter, reducing spam listing risk without blocking legitimate volume.

API Design

POST /listings — create listing in DRAFT; returns listing_id.
PUT /listings/{id} — update listing fields; triggers re-index event.
POST /listings/{id}/publish — move from DRAFT to ACTIVE; runs listing-level fraud check.
GET /search?q={query}&category={id}&min_price={n}&max_price={n}&sort={field} — search with filters.
GET /trust-scores/{entity_type}/{entity_id} — fetch current trust score with component breakdown.
POST /disputes — open a dispute against an order; triggers escrow hold.
GET /disputes/{id} — fetch dispute state and resolution detail.

Key Design Decisions

Using a transactional outbox instead of dual writes (database + Kafka in the same request) eliminates the class of bugs where a listing is written to the database but never appears in search results. Running fraud scoring synchronously at checkout rather than asynchronously prevents the race where a fraudulent transaction clears before scoring completes. Soft-deleting listings in Elasticsearch instead of hard-deleting avoids a brief window where a listing appears active in search while the index propagates the deletion.

{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “How do you design listing CRUD with search indexing in a marketplace?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Listings are written to a primary database (e.g., PostgreSQL). On create/update/delete, a transactional outbox or CDC (Change Data Capture) event is emitted and consumed by an indexer service that writes to a search engine (Elasticsearch, OpenSearch). This decouples the write path from search latency and ensures the index converges even if the indexer temporarily lags.”
}
},
{
“@type”: “Question”,
“name”: “How is buyer/seller trust scoring implemented at scale?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “A trust score is a composite of signals: transaction history, dispute rate, identity verification status, response time, and review ratings. Scores are recomputed asynchronously after each relevant event and stored in a fast-read store (Redis or a denormalized DB column). The score is exposed via an internal API consumed by ranking, fraud prevention, and UI components.”
}
},
{
“@type”: “Question”,
“name”: “What fraud prevention techniques apply to a marketplace platform?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Common techniques include: velocity checks (rate-limiting listings or purchases per account), device fingerprinting, IP reputation scoring, ML-based anomaly detection on behavioral signals, and rule engines that flag transactions above a risk threshold for manual review. High-risk actions (e.g., first payout, address change) trigger step-up verification.”
}
},
{
“@type”: “Question”,
“name”: “How does a marketplace dispute flow work end-to-end?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “A buyer opens a dispute, triggering an escrow hold on any funds not yet released. Both parties are notified and given a window to submit evidence. A rules engine attempts auto-resolution (e.g., item not delivered within SLA). If unresolved, the case is escalated to a human agent. The final decision updates the payment state (release to seller or refund to buyer) and adjusts both parties' trust scores.”
}
}
]
}