Inventory management system HLD

The key facts

• The components: a transactional record core (movements, derived quantities), an order state machine, a purchasing signal, client apps over one API, and explicit seams to accounting and storefronts.
• The data flows: receipts in, orders through fulfilment, purchase orders to suppliers, invoices to accounting — every flow reading or writing the one record.
• The HLD decisions: single record vs synced copies, derive vs store quantities, deliberate approval vs automatic deduction — made here, paid for forever.
• The companion: the LLD walkthrough descends to tables and endpoints once the HLD is settled.

The components, and why there are so few

The record core. One transactional database holding products, variants, locations, movements, orders, and purchase orders. Movements are append-only; quantities are derived. This is one component deliberately — the history of failed inventory systems is mostly a history of splitting this component into services that then disagree.

The order service. The state machine — received, validated, allocated, picked, packed, invoiced, paid, with cancellation legal until invoicing — enforced in one place, over the same database.

The purchasing signal. Reorder levels against derived stock raising draft purchase orders; goods receipts writing inbound movements; supplier invoices matched with variance flags.

The clients. Staff UI, customer portal, scanner flows — thin, all through one validated API.

The seams. Accounting (invoices out, payment status back) and storefront (order import in) as explicit, monitored integrations — never as a second path into the record.

The data flows, drawn as invariants

At HLD level, the flows matter less as arrows than as the consistency they must preserve. Receipts: goods received against a purchase order write movements immediately — the on-order figure falls as on-hand rises, in one transaction. Fulfilment: allocation reserves without consuming; invoicing consumes and deducts — the shelf and the promise stay separately true. Purchasing: a backorder's demand counts toward reorder signals, so the short line becomes a purchase order rather than a hope. Accounting: the invoice leaves with tax codes intact and payment status returns mirrored — the accounting system never receives work in progress.

Each flow carries an invariant from the design requirements: state it as a testable sentence at HLD, and the LLD inherits a specification instead of a mood.

The decisions the HLD exists to make

One record or synced copies. Synced copies drift by design; the HLD should commit to one record and thin clients, and treat every proposal to the contrary as a cost, not a feature.

Derive or store. Quantities derived from movements, with aggregates as rebuildable projections — the decision that makes every later feature trustworthy.

Deliberate or automatic deduction. Stock leaves at invoice approval, a human step — intent and fact stay separate, and cancellations stay clean.

In scope and out. The HLD's most valuable section is the exclusions: no HR, no payroll, no MRP scheduling, no tax filing — the boundary line that keeps the design small enough to be true. BSimple's HLD, for comparison, is exactly that shape: operations record, state machine, purchasing signal, clients, seams — the trial runs it on your own products, and the inventory pillar documents the record at the centre.