Design a Supplier & Vendor Portal

Problem statement

Design a Supplier & Vendor Portal for a large e-commerce marketplace. The portal allows third-party vendors to onboard, create and update product listings, manage inventory levels, track sales analytics, and receive payment disbursements after platform commission deduction. The platform merges vendor data with the main storefront catalog while preserving each vendor's operational autonomy and data isolation.

This is not a content-management dashboard. It is a multi-tenant commerce control plane where every write from vendor A must be invisible to vendor B, every inventory decrement must propagate to the storefront within seconds to prevent overselling, and every settlement calculation must be auditable to the cent. A single listing error can expose one vendor's pricing strategy to a competitor. A single inventory sync failure can oversell a product across thousands of orders. A single settlement rounding error, multiplied across 50,000 vendors and millions of transactions, becomes a material financial discrepancy.

Why this problem is distinctive

A typical CRUD application can tolerate eventual consistency and coarse-grained authorization. A vendor portal cannot. The design must solve five problems that rarely appear together in interview prep:

1. Tenant isolation at the data layer. Fifty thousand vendors share infrastructure but must never observe each other's listings, inventory, pricing, sales data, or settlement balances. A row-level security misconfiguration or a missing tenant predicate in a query is a data-breach incident, not a bug.

1. High-volume listing mutations. Vendors push bulk CSV uploads containing 100,000+ rows, update prices during flash sales, and sync inventory from external warehouse-management systems. The portal must absorb write bursts of 10,000 listing mutations per minute without degrading storefront read latency.

1. Inventory consistency between portal and storefront. The storefront displays stock counts that vendors update through the portal. If the sync is too slow, customers order out-of-stock items. If the sync uses pessimistic locking, vendor write throughput collapses. The correct answer is an event-driven projection with bounded staleness and an oversell-prevention check at order time.

1. Settlement correctness. The platform deducts a commission (typically 8-15% depending on category), applies refunds and chargebacks, calculates taxes, and disburses net amounts to vendor bank accounts on a weekly or bi-weekly cycle. Every cent must reconcile. Idempotency, double-entry bookkeeping, and immutable ledger entries are not optional.

1. Audit-grade logging. Every listing change, price update, inventory adjustment, and payout must be attributable to a specific vendor user, timestamped, and retained for compliance. Regulators and vendor disputes require a tamper-evident change history.

The four architectural planes

1. Identity & Access plane: vendor authentication, role-based access control, multi-factor authentication, API-key management, and tenant resolution.
2. Catalog & Inventory plane: listing CRUD, bulk ingestion, image pipeline, inventory sync to storefront, and search-index projection.
3. Commerce & Analytics plane: sales attribution, real-time dashboards, order linkage, and performance metrics per vendor.
4. Settlement & Compliance plane: commission calculation, ledger, disbursement, reconciliation, audit log, and regulatory reporting.

A strong interview answer keeps these planes separate. The catalog plane can degrade to eventual consistency for analytics views, but the settlement plane must never lose a ledger entry. The identity plane must reject every request that lacks a valid tenant context before any business logic executes.

Public operating baseline

Amazon reports that third-party sellers account for more than 60% of paid units on its marketplace, with over 2 million active sellers globally. Shopify's 10-K filings describe powering millions of merchants on a pod-based multi-tenant architecture. Walmart's Retail Link portal serves over 100,000 suppliers with EDI and API integrations. These are published figures that establish the category is operationally real and massive in scale.

For capacity planning, this answer explicitly assumes a mature marketplace with 50,000 active vendors, 10 million product listings, 500,000 listing mutations per day, 2 million inventory updates per day, and a 5x peak multiplier during seasonal events. Unless a number is tied to a citation, it is a stated design assumption.