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.
Design and Release a Consistent Dark-Store Inventory System
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?