ERP and Ecommerce Platform for an Auto Parts Seller

An auto parts seller ran several warehouses and an online store, but the two systems did not share data. When a customer placed an order, staff confirmed by hand whether the part was actually in stock, and when new stock arrived, inventory was updated by hand too, through calls and spreadsheets. As the business grew, inventory accuracy dropped, orders were delayed, and mistakes started reaching customers.

We built one ERP and ecommerce platform in Go that keeps stock, reservations, and sales in sync between the warehouse and the storefront in real time and checks every order against current stock. It has four connected parts: an ERP / back-office service, an admin application, the customer-facing storefront, and an asynchronous layer for integrations and background jobs.

This project is presented in a generalized form. Some details and identifying elements are intentionally omitted due to confidentiality requirements.

Discuss a Similar Project Custom Enterprise Systems

Project Context

The project had to solve several problems at once: support internal inventory and warehouse logic, keep stock, reservations, and sales synchronized, provide a fully functional ecommerce experience, enable mobile workflows for warehouse staff, and connect the platform with internal ERP and accounting systems.

What Was Delivered

ERP / Back-Office Service

The internal ERP layer handled warehouse and operational workflows. The system supported multiple warehouses, location-based storage zones, inventory movement across warehouse locations, receiving, write-offs, transfers, reservations, stock control, and inventory counts.

• multi-warehouse logic;
• location-based storage and storage zones;
• receiving, write-offs, transfers, and internal movement;
• inventory reservation;
• inventory counting;
• minimum stock levels and shortage alerts;
• document workflows for warehouse and product operations;
• warehouse dashboards and inventory turnover analytics;
• integrations with document, invoice, and barcode label printing.

Admin Application

A separate admin layer was used to manage users, roles, products, brands, categories, replacements, related products, orders, returns, shipping settings, and internal platform workflows.

• roles and access control;
• products, brands, and categories;
• replacements, equivalents, and related items;
• orders, returns, and document-related flows;
• shipping, payment, and process configuration.

Customer-Facing Ecommerce Layer

The external application was a fully functional ecommerce storefront connected to ERP logic and real stock data. Users could browse the catalog, search and filter products, view product details, add items to cart, reserve products, place orders, and pay online.

• product / parts catalog;
• search and filtering;
• real stock visibility;
• product pages and images;
• cart and checkout flows;
• product reservation;
• payment integrations;
• receipts, order history, and returns;
• equivalents, replacements, and related products.

Shipping and Cost Calculation

Shipping was implemented as a separate business layer. The platform supported integrations with cargo and delivery services and calculated shipping costs based on order parameters.

• shipping service integrations;
• shipping cost calculation;
• transfer of order and product data;
• checkout logic connected to delivery workflows;
• shipping data reflected in sales and document scenarios.

Mobile Staff Workflows

The platform also exposed API-driven workflows for warehouse staff. Staff could perform these operations from mobile devices right on the warehouse floor.

• barcode-based receiving workflows;
• write-off operations;
• warehouse tasks from mobile devices;
• staff workflows for transfers, stock updates, and operational handling.

Integrations and Internal Business Systems

The platform was connected to internal ERP, inventory, and accounting systems. This allowed the storefront, warehouse workflows, and document logic to operate as part of one connected business environment rather than separate tools.

Technology Architecture

The solution was implemented in Go with several connected service layers: an ERP / back-office layer, an admin application, a customer-facing ecommerce layer, and a separate asynchronous processing layer for integrations and background workflows. The frontend was built with Vue.js.

• Go, Vue.js;
• RabbitMQ, Redis;
• S3-compatible object storage;
• Docker and Traefik;
• Prometheus, Grafana, and centralized logging;
• API for mobile applications and internal services.

How RabbitMQ and Concurrent Processing Were Used

RabbitMQ was used as an asynchronous workflow layer for business-critical processes. It handled events and jobs related to document workflows, warehouse operations, integrations, inventory synchronization, and background processing where controlled load handling and delivery reliability were important.

Concurrent processing inside Go services was also used, but for a different purpose: faster aggregation of data, object assembly, and response preparation for the storefront, admin interfaces, and internal operational views.

Why Traefik Was Used Instead of Kubernetes

In this project, traffic balancing and routing were handled through Traefik in a Docker-based environment without introducing Kubernetes. This approach allowed the platform to distribute traffic across services, manage routing rules, and support higher load without adding unnecessary orchestration complexity.

Business Value

The storefront and the warehouse work from the same stock, reservation, and document data.

• unified ERP and ecommerce logic within one platform;
• more transparent stock, movement, and warehouse control;
• reduced manual workload for warehouse and back-office teams;
• faster warehouse operations and mobile staff workflows;
• more accurate reservation, sales, and return handling;
• less disconnect between the storefront and the internal system;
• better visibility into shipping and related operational costs.

Discuss a Similar Project View Estimated Pricing