Design and Release a Consistent Dark-Store Inventory System

Read the full interview experience this question came from →

Quick Overview

Design a consistent dark-store inventory system with relational transactions, reservations, retries, reconciliation, CI/CD, and safe Kubernetes rollout.

Design and Release a Consistent Dark-Store Inventory System

Company: Instacart

Role: Software Engineer

Category: System Design

Difficulty: medium

Interview Round: Onsite

Design an inventory system for a dark store, a fulfillment location used to prepare online orders. Prioritize consistent inventory updates and use a relational database as the authoritative store. Caching is secondary to correctness. ### Part 1 — Inventory correctness Explain the data model and operations needed to track stock, reserve it for orders, and reconcile changes during fulfillment or cancellation. Describe how concurrent requests avoid allocating the same available stock twice. State your inventory accounting assumptions. Exact operations, quantities, traffic, and availability targets are unspecified; choose a coherent minimal workflow and explain it. #### What This Part Should Cover - Store/item identity and a clear distinction between physical stock, reserved stock, and availability. - Transactions, concurrency control, and idempotent handling of retried stock-changing operations. - Reconciliation between the recorded balance and physical counts, with an audit trail. - A consistency boundary that remains authoritative even if a cache or downstream view is delayed. ### Part 2 — Release the system How would you package, test, and release the system through CI/CD and a staged rollout? Explain the relevant Kubernetes deployment concerns and how you would handle a problematic release. #### What This Part Should Cover - Reproducible artifacts and automated checks that exercise inventory failure cases. - Schema compatibility while old and new application versions overlap. - Deployment health, controlled rollout, observability, and a recovery plan that preserves committed inventory changes. ### What a Strong Answer Covers - One consistent account of reservation, fulfillment, retries, and cancellation across the schema and transaction paths. - A release plan that tests business invariants as well as process health. - Explicit limits and operational tradeoffs, without claiming that a cache or deployment rollback repairs authoritative stock data. ### Follow-up Questions - What happens if the database commits a reservation but the client times out before receiving confirmation? - How would you roll back application code after a schema migration without losing legitimate stock changes?

Overview: Design a consistent dark-store inventory system with relational transactions, reservations, retries, reconciliation, CI/CD, and safe Kubernetes rollout.

Read the full Instacart Software Engineer interview experience this question came from

|Home/System Design/Instacart
Instacart logo
Instacart
Aug 28, 2026
mediumSoftware EngineerOnsiteSystem Design
0
0

Design an inventory system for a dark store, a fulfillment location used to prepare online orders. Prioritize consistent inventory updates and use a relational database as the authoritative store. Caching is secondary to correctness.

Part 1 — Inventory correctness

Explain the data model and operations needed to track stock, reserve it for orders, and reconcile changes during fulfillment or cancellation. Describe how concurrent requests avoid allocating the same available stock twice.

State your inventory accounting assumptions. Exact operations, quantities, traffic, and availability targets are unspecified; choose a coherent minimal workflow and explain it.

What This Part Should Cover Guidance

  • Store/item identity and a clear distinction between physical stock, reserved stock, and availability.
  • Transactions, concurrency control, and idempotent handling of retried stock-changing operations.
  • Reconciliation between the recorded balance and physical counts, with an audit trail.
  • A consistency boundary that remains authoritative even if a cache or downstream view is delayed.

Part 2 — Release the system

How would you package, test, and release the system through CI/CD and a staged rollout? Explain the relevant Kubernetes deployment concerns and how you would handle a problematic release.

What This Part Should Cover Guidance

  • Reproducible artifacts and automated checks that exercise inventory failure cases.
  • Schema compatibility while old and new application versions overlap.
  • Deployment health, controlled rollout, observability, and a recovery plan that preserves committed inventory changes.

What a Strong Answer Covers Guidance

  • One consistent account of reservation, fulfillment, retries, and cancellation across the schema and transaction paths.
  • A release plan that tests business invariants as well as process health.
  • Explicit limits and operational tradeoffs, without claiming that a cache or deployment rollback repairs authoritative stock data.

Follow-up Questions Guidance

  • What happens if the database commits a reservation but the client times out before receiving confirmation?
  • How would you roll back application code after a schema migration without losing legitimate stock changes?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...