Flipkart Marketplace Platform  ·  View 13 of 25  ·  4 · Data

Core Data Model

The twelve entities that make this a marketplace rather than a shop, and the key that shards them.

Editable source SVG draw.io All views
customer customer_id PK phone_hash UQ tier created_at address address_id PK customer_id FK pincode geo_cell product product_id PK brand category_path attributes JSONB seller seller_id PK gstin UQ kyc_state risk_band order order_id PK customer_id FK state placed_at shard_key order_line line_id PK order_id FK listing_id FK qty unit_price listing listing_id PK product_id FK seller_id FK price buy_box_score inventory_ledger entry_id PK listing_id FK node_id delta reason payment payment_id PK order_id FK instrument psp_ref UQ state refund refund_id PK payment_id FK reason_code amount settlement_entry entry_id PK line_id FK type DR/CR amount cycle shipment shipment_id PK entry_id FK carrier tracking_ref state 1 : N 1 : N 1 : N 1 : N 1 : N 1 : N 1 : N 1 : N 1 : N 1 : N 1 : N Core Data Model — Marketplace Entities listing is the join that makes this a marketplace: the same product carries many seller listings, and every commercial fact hangs off the listing, not the product. v 1.0 · owner Data Architecture · date 2026-09

The listing is the architecture

  • One product carries many seller listings; price, stock, Buy Box score and commission all hang off the listing, never off the product
  • order_line references the listing, not the product, so a settlement dispute can always name the seller and the offer
  • inventory_ledger is append-only per listing per node — the current count is a projection, and the ledger is the truth

Sharding and consistency

  • Orders, lines and payments shard on a key derived from order_id so a whole order is one shard and one transaction
  • Settlement entries shard by seller for the payout run, and are reconciled against the order shard nightly
  • Catalog and listing documents live in Cosmos DB; the relational shape here is the contract, not the storage

Deliberately omitted

  • Reviews, Q&A, wishlists, coupons and cart, which are high-volume but not financially load-bearing
  • Attribute and variant modelling, which is a category-by-category schema exercise
  • Audit and event tables, which mirror every entity here
◀  Event Backbone All views Checkout and Payment Sequence  ▶
Solution Architecture v1.0 · Open source on Microsoft Azure · Enterprise Architecture · 2026-0913-core-data-model