Design scalable inventory system and avoid races

Quick Overview

This question evaluates a candidate's ability to design scalable, highly available distributed systems with robust concurrency control and consistency reasoning, covering architecture, data modeling, caching, message-based integration, and operational concerns like observability and disaster recovery.

Design scalable inventory system and avoid races

Company: Instacart

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Onsite

Design a scalable, highly available inventory management system for an e-commerce platform. Requirements: track stock across multiple warehouses; support Reserve, Release, and Purchase operations; prevent overselling under concurrent requests; provide at-least-once order events and idempotent APIs; expose read endpoints for product availability and per-warehouse breakdown; support flash-sale spikes (e.g., 50k RPS reads, 5k RPS writes). Specify: overall architecture (services, databases, caches, message buses), data model (items, warehouses, reservations, versioning), consistency model (strong vs. eventual) and why, strategies to avoid race conditions (optimistic concurrency/version numbers, conditional updates, idempotency keys, quorum or distributed locks where needed), scaling strategies (read replicas, sharding, write queues, CQRS), cache design and invalidation, handling of partial failures and retries, exactly-once semantics at boundaries, backpressure and rate limiting, observability (metrics, tracing), disaster recovery, and multi-region considerations.

Quick Answer: This question evaluates a candidate's ability to design scalable, highly available distributed systems with robust concurrency control and consistency reasoning, covering architecture, data modeling, caching, message-based integration, and operational concerns like observability and disaster recovery.

|Home/System Design/Instacart
Instacart logo
Instacart
Sep 6, 2025, 12:00 AM
hardSoftware EngineerOnsiteSystem Design
29
0

System Design: Scalable, Highly Available Inventory Management

Context

Design an inventory management system for a high-traffic e-commerce platform that tracks stock across multiple warehouses and supports real-time purchasing flows. The system must remain correct under high concurrency and flash-sale spikes.

Functional Requirements

  • Track inventory by product across multiple warehouses.
  • Operations (all idempotent):
    1. Reserve: hold stock for an order with expiry (TTL).
    2. Release: free a reservation (manual or TTL expiry).
    3. Purchase: convert a reservation to a committed order and decrement available stock.
  • Prevent overselling under concurrent requests.
  • Emit order/inventory events with at-least-once delivery.
  • Read endpoints:
    • Get product availability (global total and per-warehouse breakdown).

Non-Functional Requirements

  • Flash-sale workload: ~50k RPS reads, ~5k RPS writes.
  • High availability and horizontal scalability.
  • Idempotent APIs; at-least-once events; exactly-once semantics at service boundaries where feasible.

Specify

  • Overall architecture (services, databases, caches, message buses).
  • Data model (items, warehouses, reservations, versioning).
  • Consistency model (strong vs eventual) with justification.
  • Concurrency control and race-condition avoidance strategies (optimistic concurrency, conditional updates, idempotency keys, selective locks/quorum if needed).
  • Scaling strategies (read replicas, sharding, write queues, CQRS).
  • Cache design and invalidation.
  • Handling of partial failures and retries.
  • Exactly-once semantics at boundaries.
  • Backpressure and rate limiting.
  • Observability (metrics, tracing).
  • Disaster recovery and multi-region considerations.

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...