Warehouse Handling and Reporting System

Problem Design a warehouse handling and reporting system that tracks inventory across multiple warehouse locations, records every stock movement, and produces operational reports. Deliverables include a class diagram, a sequence diagram for the movement flow, and working code for the key operations using at least one design pattern.

Requirements

• receiveStock(warehouseId, sku, qty) / dispatchStock(warehouseId, sku, qty) -> StockMovement
• transferStock(fromWarehouseId, toWarehouseId, sku, qty) -> StockMovement
• getStockLevel(warehouseId, sku) -> int and getMovementHistory(sku, dateRange) -> List<StockMovement>
• generateReport(type, dateRange) -> Report for daily/weekly summaries
• Subscribe/notify hooks for threshold breaches: subscribe(listener)

Core design

• Warehouse composes InventoryItem records (sku, quantity, location/bin); InventoryItem is the unit of stock accounting.
• StockMovement carries a MovementType enum (INBOUND, OUTBOUND, TRANSFER), sku, quantity, source/destination, and timestamp. A TRANSFER is modelled as a paired outbound + inbound so ledgers stay balanced.
• Movements are append-only: stock levels are derived from (or reconciled against) the movement log rather than blindly overwritten.
• ReportGenerator with the Strategy pattern — one strategy per report type (daily summary, weekly summary, movement history) sharing a common Report generate(dateRange) interface.
• Observer pattern for alerting: a LowStockAlertService subscribes to inventory changes and fires when a sku crosses its reorder threshold.
• Factory constructs the correct StockMovement subtype from a request, keeping construction rules out of the service layer.

Core flow (sequence) Movement request -> validate (sku exists, sufficient stock for outbound, valid destination) -> persist StockMovement -> update InventoryItem -> notify observers -> return result.

Discussion points

• Concurrency: two dispatches racing on the same sku can oversell. Guard with per-item locking or an atomic conditional update (UPDATE ... WHERE qty >= n), and decide whether negative stock is ever tolerated.
• Edge cases: partial transfers, in-flight stock that has left one warehouse but not yet arrived, reversals/corrections of a bad movement (compensating entry, never a delete).
• Trade-off: derived stock levels (replay the log, always auditable, slower reads) vs. a materialised quantity column (fast reads, needs reconciliation).
• Extension: multi-bin locations, batch/expiry tracking, and reservation of stock for pending orders.