Architecting Scalable Multi-Vendor eCommerce Platforms: Database Partitioning, Real-Time Inventory & Checkout

The most catastrophic failure in eCommerce is overselling inventory—confirming a purchase for stock that does not physically exist. In high-concurrency environments, naive database updates like UPDATE products SET stock = stock - 1 WHERE id = 123 lead to race conditions when multiple worker processes execute concurrently.

To guarantee atomic consistency without locking the primary relational database, modern platforms employ a Two-Phase Redis Reservation Pattern:

When a buyer enters the checkout funnel, the stock is reserved in Redis for 10 minutes. If payment succeeds, the relational database commits the transaction asynchronously. If payment fails or the session expires, the stock is automatically restored to the Redis pool. This decouples fast checkout traffic from persistent disk I/O.

As marketplace order volume grows into millions of records, querying monolithic tables degrades performance. To maintain sub-50ms query response times, database engineers implement Command Query Responsibility Segregation (CQRS) combined with table partitioning:

• Write Pipeline (Commands): Handles order placement, inventory deductions, and payment authorizations on a high-availability PostgreSQL primary database using row-level locking.
• Read Pipeline (Queries): Read-heavy operations (browsing category catalogs, searching filters, product detail views) are routed to geographically distributed read replicas and Elasticsearch clusters.
• Time-Based Range Partitioning: The orders table is partitioned by month or quarter (e.g., orders_2026_q1), allowing old historical data to be archived to colder storage without impacting live indexing.

Learn more about our database engineering in our Backend Development Services.

Multi-vendor marketplaces require complex payment splitting architectures (e.g., Stripe Connect, Razorpay Route, Adyen). When a customer pays $100 for a cart split between Vendor A ($60) and Vendor B ($40), the platform deducts a 10% platform fee and distributes net payouts accordingly.

Because payment gateways communicate via asynchronous webhooks, network retries can trigger duplicate webhook events. To prevent double payments, every webhook handler must be strictly idempotent:

async function handlePaymentWebhook(event) {
  const eventId = event.id; // Unique gateway identifier
  
  // Check if this event was already processed
  const processed = await redis.set(`webhook:${eventId}`, 'LOCKED', 'NX', 'EX', 86400);
  if (!processed) {
    return { status: 'already_processed' }; // Ignore duplicate delivery
  }

  // Execute financial ledger transaction in atomic DB session
  await db.transaction(async (trx) => {
    await trx.orders.updateStatus(event.orderId, 'PAID');
    await trx.vendorLedger.recordPayouts(event.splitPayouts);
  });
}

This guarantees that regardless of how many times a payment gateway retries a webhook, the vendor balance is credited exactly once.