Node.js Retail Inventory Platform: Building a Real-Time Stock, Order Allocation, Store Replenishment, and Omnichannel Fulfillment System

Project: Node.js Backend Development, Real-Time Inventory Platform, Omnichannel Order Allocation, Store Replenishment Automation, Stock Transfer Workflow, and Retail Operations API

Duration: 23 weeks

UrbanNest Retail sells home decor, kitchenware, small furniture, lighting, and lifestyle products through 34 physical stores, an online shop, and two regional fulfillment locations. As customer demand shifted toward click-and-collect, ship-from-store, and same-day local delivery, the company's inventory processes became harder to control. Store stock was updated in batches, online availability was sometimes inaccurate, transfer requests were handled through spreadsheets, and replenishment planning relied heavily on manual judgment. Store managers often discovered stock discrepancies only after customers placed orders. Customer support teams had to contact stores manually to confirm whether products were available. UrbanNest did not need a full ERP replacement. It needed a Node.js backend layer that could centralize inventory events, expose real-time stock APIs, automate order allocation, and improve store replenishment decisions.

UrbanNest's inventory data was fragmented and delayed. Online customers sometimes bought products that stores could not actually fulfill. Store teams used spreadsheets to request transfers and replenish fast-moving items. Customer support agents checked availability manually by calling stores. Operations managers lacked a live view of sell-through, stockouts, transfer delays, and fulfillment risk. As order volume increased, inaccurate stock data caused cancellations, customer complaints, manual correction work, and lost sales.

Business signals

• Online product availability was not always accurate because store and warehouse stock updated in delayed batches.
• Store managers used spreadsheets and emails to request stock transfers.
• Customer support teams manually contacted stores to confirm product availability.
• Click-and-collect orders were sometimes accepted even when stock had already been sold in-store.
• Replenishment planning depended too much on manual review instead of live demand signals.
• Operations teams lacked a single view of stock across stores, warehouses, online reservations, returns, and damaged inventory.
• Order allocation rules were inconsistent across e-commerce, store pickup, local delivery, and warehouse fulfillment.
• Stock discrepancies caused cancellations, refunds, and poor customer experience.
• Slow transfer approvals delayed movement of high-demand products between locations.
• The business wanted omnichannel fulfillment improvements without replacing the POS, warehouse, and e-commerce systems immediately.

Technical signals

• Inventory events came from POS terminals, e-commerce orders, warehouse scans, returns, transfers, and manual adjustments.
• Some systems sent delayed or duplicate stock events during network issues.
• Stock reservations needed expiry rules to avoid locking inventory indefinitely.
• Order allocation required location, channel, stock, delivery speed, fulfillment capacity, and margin rules.
• Store-level safety stock needed to protect shelves from being emptied by online orders.
• Inventory updates required real-time visibility for dashboards and customer-facing availability.
• Returns and damaged stock needed separate workflows because not all returned items could be resold.
• Transfer requests needed approval, picking, dispatch, receiving, and reconciliation states.
• The platform needed APIs for e-commerce availability, internal dashboards, store tools, and reporting.
• Reporting queries had to support large transaction history without slowing operational APIs.
• Authentication and authorization had to separate store users, warehouse users, support agents, managers, and API clients.
• Deployment needed monitoring, database backups, queue visibility, and rollback-safe releases.

Metrics Online Stock Accuracy: Estimated 86% to 90% depending on product category and store location

Single Live Stock View: No reliable real-time stock view across all locations

Replenishment Planning Time: 7 to 10 hours per week

Average Transfer Approval Time: 18 to 36 business hours

Return To Resell Decision Delay: Often 1 to 3 business days

Click And Collect Exception Rate: 9.4% of orders required manual store confirmation

Inventory Reporting Preparation: 6 to 8 hours per week

Manual Store Availability Checks: 1,100+ support and operations checks per month

Stock Reservation Expiry Visibility: No consistent process across channels

Monthly Cancelled Orders Due To Stock Issues: 280 to 430 orders

Pages Measured

• Online stock availability
• Click-and-collect order flow
• Store transfer workflow
• Replenishment planning
• Warehouse dispatch process
• Returns handling
• Customer support stock lookup
• Order allocation process
• Inventory adjustment review
• Weekly retail operations reporting

Primary Audience: Store managers, warehouse teams, e-commerce operations, customer support agents, finance users, retail operations managers, and online customers

Measurement Window: 60 days before implementation

The discovery process focused on understanding inventory movement, fulfillment rules, store workflows, warehouse operations, e-commerce availability requirements, transfer approval processes, and reporting needs. The team confirmed that Node.js was a strong fit because UrbanNest needed fast APIs, event-driven inventory processing, real-time updates, and flexible integrations across retail systems.

What we inspected

• Title: Stakeholder interviews

  Description: The team interviewed store managers, warehouse supervisors, e-commerce operations, customer support agents, finance users, merchandising leads, and retail operations managers to identify stock visibility gaps and manual workflows.

• Title: Inventory lifecycle mapping

  Description: The project mapped inventory movement from purchase order receipt, warehouse storage, store delivery, POS sale, online reservation, order allocation, transfer, return, damage review, adjustment, and replenishment recommendation.

• Title: System integration review

  Description: Existing POS, e-commerce, warehouse, finance, and reporting systems were reviewed for API capabilities, webhook support, export formats, event delays, failure modes, and data ownership.

• Title: Order allocation rule design

  Description: The team documented fulfillment rules for warehouse delivery, store pickup, ship-from-store, local delivery, partial fulfillment, safety stock, priority customers, and product restrictions.

• Title: Stock reservation analysis

  Description: Reservation rules were reviewed for online checkout, abandoned baskets, unpaid orders, click-and-collect holds, transfer holds, and manual customer service reservations.

• Title: Transfer workflow review

  Description: The team reviewed how store transfer requests were created, approved, picked, dispatched, received, rejected, and reconciled.

• Title: Reporting requirement review

  Description: Operations leaders defined reporting needs for stockouts, aged inventory, transfer delays, cancellation reasons, sell-through, replenishment demand, and location-level availability.

• Title: Technical architecture planning

  Description: The team selected Node.js and Express.js for APIs, PostgreSQL for inventory records, Redis for event queues and active stock caching, Socket.IO for live dashboard updates, Docker for deployment consistency, and AWS for hosting.

The main challenge was to build a reliable inventory platform that could support real-time stock updates across stores, warehouses, online orders, returns, transfers, reservations, damaged items, and replenishment workflows. Retail inventory changes constantly, and the system had to prevent overselling while still keeping stock available for the right channels. The platform needed to handle stock reservations, partial fulfillment, store-level availability, safety stock rules, order priority, transfer approval, and exception handling. It also had to integrate with point-of-sale software, the e-commerce platform, warehouse systems, and finance exports without disrupting active store operations.

The solution was a Node.js-based inventory and order allocation platform that centralized stock events, normalized inventory changes, managed reservations, automated fulfillment decisions, supported store transfers, and exposed real-time availability APIs. The platform became the operational inventory layer above existing POS, e-commerce, warehouse, and finance systems.

Strategy

• Build a Node.js backend for inventory events, stock balances, reservations, order allocation, transfers, replenishment, returns, and reporting.
• Use PostgreSQL to store products, locations, stock ledgers, reservations, orders, transfers, returns, adjustments, replenishment signals, and audit logs.
• Use Redis for active stock caching, event processing, reservation expiry, and dashboard performance.
• Use Socket.IO to stream stock changes, transfer updates, allocation exceptions, and replenishment alerts to internal dashboards.
• Normalize incoming stock events from POS, e-commerce, warehouse, returns, transfers, and manual adjustment tools.
• Create order allocation rules that consider availability, channel, location, safety stock, fulfillment capacity, delivery promise, and business priority.
• Add stock reservation workflows with expiry, release, conversion, and audit history.
• Replace spreadsheet transfer requests with a structured approval and reconciliation workflow.
• Create APIs for e-commerce availability, support stock lookup, store tools, warehouse workflows, and management reporting.
• Deploy with automated testing, monitoring, structured logs, backups, and staged rollout controls.

Phase1 Title: Node.js platform foundation and inventory domain model

Actions

• Created backend modules for products, locations, stock, reservations, orders, allocations, transfers, returns, replenishment, integrations, reporting, and authentication.
• Designed PostgreSQL tables for SKUs, variants, locations, stock balances, stock ledger entries, reservations, orders, fulfillment decisions, transfers, return inspections, adjustments, and audit events.
• Configured environment-based settings for local development, staging, and production.
• Created database migrations for repeatable schema changes.
• Added validation utilities for SKU references, location codes, stock quantities, channel rules, reservation expiry, and adjustment reasons.
• Configured structured logging with request IDs, SKU references, location IDs, source systems, and error context.
• Created seed data for store locations, warehouses, sales channels, product categories, and service rules.
• Added automated tests for stock balance updates, reservation creation, reservation release, and basic allocation behavior.

Description: The first phase established the backend structure, database model, service boundaries, and core inventory entities.

Phase2 Title: Authentication, authorization, and operational access control

Actions

• Implemented token-based authentication for internal users and integration clients.
• Created role-based permissions for store users, store managers, warehouse users, customer support agents, operations managers, finance users, and system administrators.
• Restricted store users to their assigned locations while allowing regional managers broader visibility.
• Created scoped API credentials for e-commerce, POS, warehouse, and reporting integrations.
• Added audit logs for stock adjustments, transfer approvals, reservation overrides, allocation changes, and user access.
• Added rate limiting for public-facing availability APIs.
• Created permission checks for high-risk actions such as manual stock correction and transfer cancellation.
• Logged failed authorization attempts for security and operational review.

Description: Access control was designed around store roles, warehouse roles, support roles, managers, and system integrations.

Phase3 Title: Inventory event ingestion and stock ledger

Actions

• Created ingestion endpoints for POS sales, e-commerce reservations, warehouse receipts, returns, transfer dispatches, transfer receipts, damages, and manual adjustments.
• Normalized incoming stock payloads into ledger entries with SKU, location, quantity change, source system, event type, source timestamp, and received timestamp.
• Added idempotency keys to prevent duplicate POS or warehouse events from changing stock twice.
• Created stock balance recalculation logic from ledger entries.
• Stored raw payloads for debugging and reconciliation.
• Added validation for negative stock rules, unknown SKUs, inactive locations, unsupported event types, and missing references.
• Created exception queues for failed events requiring manual review.
• Added monitoring for event volume, event latency, duplicate events, failed events, and stock reconciliation differences.

Description: The stock ledger became the reliable record of inventory movement. Every stock change was represented as an event with source, reason, quantity, location, and timestamp.

Phase4 Title: Real-time stock availability API

Actions

• Created APIs for SKU availability by location, channel, delivery method, and customer-facing fulfillment option.
• Separated physical stock, reserved stock, damaged stock, transfer stock, safety stock, and sellable stock.
• Cached active availability data in Redis for high-traffic products.
• Created customer-safe availability states such as in stock, low stock, unavailable, available for pickup, and available for delivery.
• Added API fallback behavior when upstream systems were delayed.
• Used Socket.IO to broadcast stock changes to internal dashboards.
• Added rate limits and caching headers for e-commerce availability calls.
• Created tests for stock visibility rules, safety stock protection, reservation impact, and location-level availability.

Description: The availability API gave e-commerce, support teams, and store tools a faster and more reliable view of sellable stock.

Phase5 Title: Order allocation and fulfillment decision engine

Actions

• Created allocation rules for warehouse fulfillment, click-and-collect, ship-from-store, local delivery, split shipment, and manual review.
• Considered stock availability, safety stock, delivery postcode, fulfillment capacity, store opening hours, product restrictions, and order priority.
• Created reservation records when stock was allocated to an order.
• Added reservation expiry rules for unpaid, abandoned, failed, cancelled, and timed-out orders.
• Created manual review queues for allocation conflicts, low stock, partial fulfillment, and restricted SKUs.
• Stored allocation decisions with rule explanations for support and operations users.
• Allowed authorized users to override allocation when business exceptions required it.
• Added tests for stock conflicts, safety stock rules, split fulfillment, reservation expiry, and allocation failure scenarios.

Description: The allocation engine decided where an order should be fulfilled from while reducing cancellations and protecting store operations.

Phase6 Title: Store transfer workflow

Actions

• Created transfer request APIs for store-to-store, warehouse-to-store, store-to-warehouse, and emergency stock movement.
• Added transfer statuses for requested, approved, rejected, picking, dispatched, in transit, received, partially received, cancelled, and reconciled.
• Created approval rules based on source location, destination location, SKU value, quantity, demand level, and regional manager ownership.
• Reserved stock during approved transfer picking to prevent it from being sold before dispatch.
• Added receiving workflows for destination stores to confirm quantities.
• Created discrepancy handling for missing, damaged, or incorrect items.
• Stored transfer history and audit logs for every state change.
• Created dashboards for pending approvals, overdue transfers, in-transit stock, and reconciliation issues.

Description: The transfer module replaced spreadsheet requests with structured movement between locations.

Phase7 Title: Returns and damaged stock workflow

Actions

• Created return intake APIs for online returns, store returns, courier returns, and warehouse returns.
• Added inspection states for pending review, resellable, damaged, repair required, supplier return, disposal, and manual review.
• Separated returned stock from sellable stock until inspection was completed.
• Linked return records to original orders where available.
• Created adjustment events when returned items became sellable or were marked damaged.
• Added reason codes for damage, customer return, incorrect item, packaging issue, and quality review.
• Created reporting for return rates by SKU, category, store, and channel.
• Added audit logs for stock status changes caused by return inspections.

Description: Returns needed clear inspection and resale rules because returned items could not always go directly back into sellable inventory.

Phase8 Title: Replenishment recommendation APIs

Actions

• Created replenishment signals based on sell-through, current stock, reserved stock, incoming transfers, safety stock, recent demand, and category rules.
• Generated suggested replenishment quantities by SKU and location.
• Added filters for urgent stockouts, fast-moving products, aged inventory, seasonal items, and high-margin products.
• Created manager review workflows before suggestions became transfer or purchase requests.
• Allowed rejected suggestions to capture reason codes for future tuning.
• Created daily summary jobs for replenishment calculations.
• Added APIs for merchandising and operations dashboards.
• Improved stock planning by replacing manual spreadsheet consolidation with structured recommendations.

Description: The replenishment module helped store managers and operations teams identify stock movement needs before stockouts occurred.

Phase9 Title: Operations reporting and reconciliation

Actions

• Created reporting APIs for stockouts, low stock, cancelled orders, allocation failures, transfer delays, return rates, sell-through, and location-level availability.
• Added reconciliation reports comparing stock balances against POS, warehouse, and e-commerce source records.
• Created daily inventory snapshots for reporting performance.
• Built support search APIs for SKU, product name, order reference, location, customer order, reservation, and transfer ID.
• Added finance export signals for completed fulfillments, cancelled stock reservations, and returned inventory outcomes.
• Created exception reports for negative stock, repeated discrepancies, failed events, and manual override frequency.
• Added exportable reports for retail operations meetings.
• Reduced weekly reporting effort by centralizing inventory history and fulfillment records.

Description: The reporting layer gave leadership better visibility into stock accuracy, fulfillment health, transfer performance, and sales risk.

Phase10 Title: Testing, deployment, monitoring, and staged rollout

Actions

• Added automated tests for stock events, reservations, allocation rules, transfer workflows, returns, replenishment logic, permissions, and integration failures.
• Configured CI checks for linting, tests, migration validation, and container builds.
• Containerized the Node.js services using Docker.
• Deployed the platform on AWS with managed database services, object storage, logging, monitoring, and backup configuration.
• Added monitoring for event queues, inventory drift, API latency, failed integrations, reservation expiry jobs, and socket connections.
• Created rollback procedures for application releases and database migrations.
• Ran a pilot with five stores and one warehouse before expanding to all locations.
• Trained store managers, warehouse teams, support agents, e-commerce operations, and retail operations managers.
• Collected pilot feedback and improved stock terminology, transfer filters, exception queues, dashboard layouts, and allocation explanations.
• Completed full rollout after validating stock accuracy, order allocation, transfer handling, and e-commerce availability behavior.

Description: The final phase focused on production reliability, safe adoption, and operational confidence across stores and warehouses.

• Online stock accuracy improved because availability was calculated from normalized stock events, reservations, safety stock, and location-level rules.
• Cancelled orders caused by stock issues decreased as the allocation engine protected against overselling.
• Customer support teams answered stock questions faster through centralized availability lookup.
• Click-and-collect exceptions decreased because reservations were created when orders were allocated.
• Store transfer requests became structured, trackable, and auditable instead of spreadsheet-based.
• Replenishment planning became faster through suggested stock movement based on demand and current availability.
• Operations managers gained live visibility into stockouts, low-stock products, transfer delays, allocation failures, and return outcomes.
• Duplicate and delayed stock events became easier to detect through idempotency keys and reconciliation reports.
• Returns handling improved because resellable, damaged, and review-required items were separated clearly.
• Warehouse and store teams gained better coordination around transfer picking, dispatch, receiving, and discrepancies.
• Finance users received cleaner fulfillment and return signals for reporting and reconciliation.
• The business reduced manual calls, spreadsheet transfer requests, delayed stock checks, and weekly reporting work.
• The Node.js platform created a reusable foundation for future store apps, advanced forecasting, supplier integrations, and customer-facing availability improvements.
• UrbanNest gained stronger omnichannel fulfillment capability without replacing its POS, warehouse, and e-commerce platforms.

The Node.js inventory platform gave UrbanNest Retail a real-time operational layer for stock visibility, order allocation, reservations, store transfers, returns, replenishment, and reporting. Online customers received more accurate availability, store teams reduced manual transfer work, support agents answered stock questions faster, and operations leaders gained better control over fulfillment risk.

Outcomes

• Reduced cancelled orders caused by inaccurate stock data.
• Improved customer experience through more reliable online availability and click-and-collect workflows.
• Reduced manual workload for store managers, support agents, warehouse teams, and operations staff.
• Improved stock transfer visibility through structured approval and reconciliation workflows.
• Better replenishment planning based on demand signals and location-level stock.
• Improved support response speed through centralized stock and reservation lookup.
• Stronger inventory auditability through ledger-based stock events.
• Better returns control by separating damaged, review-required, and resellable stock.
• Lower risk compared with full ERP or POS replacement because the platform integrated with existing systems.
• A reusable Node.js foundation for advanced retail automation, forecasting, and omnichannel fulfillment.

• Use Node.js for the inventory API layer.

  The project required fast APIs, event ingestion, real-time updates, integration handling, and high-volume availability checks. Node.js fit the I/O-heavy retail workload well.

• Use a stock ledger instead of only storing current balances.

  A ledger gave the business a traceable history of stock movement, making reconciliation, audits, debugging, and reporting more reliable.

• Separate physical stock from sellable stock.

  Retail availability depends on reservations, damages, returns, transfers, and safety stock. Physical quantity alone could not safely drive customer-facing availability.

• Use Redis for active availability caching.

  E-commerce traffic could create heavy availability lookup demand. Redis improved response times while PostgreSQL remained the structured source of truth.

• Add idempotency controls for inventory events.

  POS and warehouse systems could send duplicate or delayed events. Idempotency prevented stock balances from being corrupted.

• Build order allocation as a rule-based service.

  Fulfillment decisions needed to consider channel, location, stock, safety stock, delivery promise, capacity, and business priority.

• Use structured transfer workflows instead of spreadsheet requests.

  Transfers affected sellable inventory and needed approval, picking, dispatch, receipt, discrepancy handling, and audit history.

• Keep existing POS, warehouse, and e-commerce systems.

  Replacing core systems would have increased risk. The Node.js layer solved inventory visibility and fulfillment problems while preserving existing tools.

• Create daily inventory snapshots for reporting.

  Operational APIs needed to stay fast. Snapshot tables allowed reporting without slowing stock updates and availability checks.

• Pilot with selected stores before full rollout.

  Store operations vary by team, location, product category, and fulfillment method. A staged rollout revealed practical workflow issues before broad adoption.

• Retail inventory platforms must distinguish physical stock, sellable stock, reserved stock, damaged stock, and transfer stock.
• Node.js works well for omnichannel inventory systems that depend on fast APIs and event-driven updates.
• A stock ledger makes troubleshooting and reconciliation much easier than current-balance-only designs.
• Stock reservations need expiry and release rules or they will quietly reduce sellable inventory.
• Customer-facing availability should be simplified, but internal inventory logic must remain precise.
• Order allocation creates business value when it protects both customer promises and store operations.
• Transfer workflows need audit history because inventory movement affects availability and finance reconciliation.
• Returns should not automatically become sellable stock without inspection rules.
• Real-time dashboards are useful only when event quality and status rules are reliable.
• Pilot stores expose workflow problems that central operations teams often miss.
• Inventory reporting should be separated from operational stock updates for performance.
• The best omnichannel systems reduce overselling without hiding stock needed for stores, customers, and fulfillment teams.

Role: Head of Retail Operations

Quote: The platform gave us the inventory visibility we needed to support omnichannel growth. Stores, e-commerce, support, and operations now work from the same stock picture instead of chasing updates across spreadsheets and separate systems.

Person: Sophie Turner

Company: UrbanNest Retail

UrbanNest Retail used Node.js to create a real-time inventory and order allocation platform for stock events, availability APIs, reservations, click-and-collect, store transfers, returns, replenishment, reporting, and system integrations. The project avoided replacing existing POS, warehouse, and e-commerce platforms and instead introduced a scalable backend layer with PostgreSQL, Redis, Socket.IO, Docker, AWS, stock ledger logic, role-based permissions, event normalization, and structured workflows. The result was more accurate stock visibility, fewer cancelled orders, faster support responses, better transfer control, stronger replenishment planning, improved returns handling, and a reusable foundation for future omnichannel retail automation.