Jerick SonIcamina

Problem

The company tracked inventory in spreadsheets. When a receiving clerk logged inbound stock, that update wasn't visible to the picking team until someone manually reconciled the sheet — sometimes hours later. This created a class of problems: overselling products that were committed but not yet shelved, stock "appearing" in the wrong zone because location updates lagged behind physical movement, and fulfillment delays because pickers couldn't trust what the spreadsheet said was available. At the operational level, the root cause was simple: no single source of truth for stock state, and no transactional guarantees when multiple people modified inventory simultaneously.

Solution

Designed and led development of IRIS — a system that replaced the entire spreadsheet-based workflow with transactional inventory management. The core design principle was that every stock movement (receive, put-away, pick, transfer, adjustment) is recorded as an immutable event, and current stock levels are derived from the event log. This gave the operations team an auditable history of every unit that moved through the warehouse, and gave the system a foundation for enforcing consistency even under concurrent access.

Scale

Thousands of active SKUs across multiple warehouse zones. Concurrent daily users across receiving, picking, and shipping stations. The system handles the full inventory lifecycle — from purchase order receipt through customer shipment — processing stock movements continuously throughout the operating day.

Architecture

Golang was chosen for the backend because the core domain is concurrent stock manipulation — goroutines and channels map naturally to handling simultaneous warehouse operations without the overhead of a JVM or the concurrency complexity of Node.js. PostgreSQL was selected over MySQL for its row-level locking semantics and SERIALIZABLE isolation support, which were critical for the inventory consistency model. The Svelte web dashboard serves warehouse managers and back-office staff. React Native was chosen for the mobile app because floor staff need barcode scanning and location confirmation on devices that may lose connectivity between warehouse zones.

Data Model

The inventory model is event-sourced at the movement level. A stock_movements table records every unit change with a movement type (RECEIVE, PUTAWAY, PICK, TRANSFER, ADJUST, SHIP), source/destination location, quantity delta, and a reference to the originating order or transfer. Current stock levels are materialized in a stock_on_hand view partitioned by (sku_id, location_id). Each SKU-location pair carries a version counter used for optimistic concurrency control — any write that finds a stale version is rejected and retried. Warehouse locations follow a zone → aisle → rack → bin hierarchy, modeled as a nested set for efficient subtree queries when checking zone-level availability.

Engineering Challenges

Trade-offs

Chose Golang over Node.js for the backend despite the team having more TypeScript experience. The concurrency primitives (goroutines, channels, select) made the stock processing pipeline significantly cleaner than callback-based alternatives, and the compiled binary simplified deployment to the on-premise server. Chose event-sourced stock movements over a simpler current-state-only model because auditability was a hard requirement — operations needed to trace exactly how stock levels arrived at their current values. The cost is higher storage and slightly more complex queries, but the debugging and reconciliation benefits justified it. Chose optimistic concurrency (version checks) over pessimistic locking for most operations because throughput mattered more than strict ordering — warehouse operations are high-frequency but low-contention at the individual SKU-location level.

Failure Handling

If the backend goes down mid-pick, the mobile app's local buffer holds the operation until reconnection. Partially completed multi-item picks are tracked as in-progress; if not completed within a configurable timeout, they're automatically rolled back and the reserved stock is released. If PostgreSQL enters a degraded state, the system switches to read-only mode — staff can view current stock but cannot process movements until the database recovers. This prevents silent data corruption during partial availability.

Impact

Eliminated spreadsheet-based tracking entirely — the company now operates on a single, transactional source of truth for all inventory. Stock discrepancy rate dropped from regular manual reconciliation events to exception-only investigation. Order fulfillment shifted from a multi-step, error-prone manual process to a guided mobile workflow that enforces correctness at each step. The system processes the full daily operational throughput without manual intervention.