Inventory system scaling and launch checklist

• Pagination: Item, movement and PO lists use keyset pagination on (created_at, id) or (sku, id); page size <= 100; scan lookups are single indexed reads.
• Caching: Item masters and UOM tables are cached in memory by (id, updated_at); availability reads come from stock_balances, never SUM over moves at request time.
• Idempotency: Every stock move, receipt and import commit carries an idempotency key with a unique constraint so scanner retries and flaky Wi-Fi never double-receive.
• Idempotency: Balance updates lock rows in ascending (item, lot, location) order within one transaction; reservations use an atomic conditional update (reserved <= on hand) to prevent overselling under concurrency.
• Rate limits: Per-user and per-API-key limits on movement and import endpoints; storefront reservation webhook has per-integration limits and payload caps.
• Data growth: stock_moves and audit_log are partitioned by month; closed periods are detached to read-only archive and never dropped within retention.
• Search: Item and supplier search uses trigram and full-text indexes with barcode and SKU exact-match fast paths.

• Metric stock moves total and post latency ms: by kind and warehouse, including lock wait.
• Metric match exceptions open: open three-way match exceptions by age.
• Metric stockout items: items with zero available and open demand.
• Log procurement audit log: request id, actor, document ids, outcome; no bank details.
• Trace receive trace: scan, balance update, PO status update, notification.
• Slo inventory accuracy: cycle count variance under 1% of lines; below that is reported monthly.
• Slo stock ledger correctness: 0 negative balances where disallowed, 0 duplicate moves per idempotency key.
• Alert balance drift: cache differs from moves: freeze item moves and page.

• compute_reorder_suggestions: runs cron nightly. Guard: creates draft requisitions only, one open draft per item and warehouse, bounded batch.
• verify_stock_balances: runs cron nightly. Guard: recompute balances from stock_moves in bounded batches; mismatch freezes moves for the item and alerts.
• flag_late_pos_and_expiry: runs cron daily. Guard: notifies buyers of late POs and lots near expiry once per threshold.
• valuation_snapshot: runs cron monthly. Guard: idempotent per (org, period); stored for the finance close.
• expire_reservations: runs cron every 5 minutes. Guard: releases stale reservations from abandoned orders in bounded batches.
• verify_audit_chain: runs cron nightly. Guard: incremental hash chain recompute, break is a sev-1.

• Read replicas: Valuation, aging and supplier analytics run on a read replica when primary CPU > 60% sustained; posting always uses the primary.

Forge64 matches your description to one of 25 reference architectures, writes the plan and data model into the project, generates the app, and runs a quality gate over the code before you see it. Each app gets its own Postgres database and sign-in with no per-user fee. Hosting on Forge Cloud and Forge Payments are rolling out.

Every metered resource on Forge64 has a hard cap, so a traffic spike stops at your limit instead of becoming a surprise bill. This is a reference design for the category, not a promise that every item is generated today. Built-ins such as background jobs, file uploads and search are rolling out; email sent from your app is coming soon, so anything here that needs it is something you add yourself for now.

When should I worry about scale for an inventory system?

Not before a measured trigger fires. For example, for "EDI (X12/EDIFACT) and AS2/SFTP supplier connectors": a supplier needing EDI is signed.

What performance targets should an inventory system aim for?

Barcode scan to movement posted: p95 < 200 ms including balance update. Stock availability lookup: p95 < 40 ms single indexed read. PO board page (50 rows): p95 < 150 ms.

Does Forge64 cap my usage costs?

Yes. Every metered resource has a hard cap, and paid plans add an overage spend cap that you set.

• How to build an inventory system
• Inventory system architecture
• Example prompt for an inventory system
• Inventory system security checklist
• Often combined: online store
• Often combined: accounting system
• All app types