izharishaksa/ecommerce-system-example

This system is a microservices-based order management platform comprising customer, order, and inventory services, all written in Go. It exposes REST APIs for managing customer accounts, placing orders, and tracking stock levels, while using Kafka to handle asynchronous event-driven communication between services. The architecture relies on an in-memory data store for immediate persistence and a shared library for common configuration and error handling utilities.

The inventory-service now includes a Kafka client package that sets up consumers for order-related events. It defines a generic consumer loop in consumer.go, a handler implementation in handler.go that deserializes and processes 'OrderPlaced' messages via the use-case layer, and a router in router.go that starts background consumers for 'ORDER\_PLACED', 'ORDER\_CREATED', and 'ORDER\_CANCELED' topics.

inventory-service/cmd/kafkaclient · high confidence

The order-service now includes a Kafka client package that consumes messages from the 'ORDER' topic within the 'ORDER\_GROUP' consumer group. This client deserializes incoming JSON payloads into order-specific structs and routes them to internal service handlers for processing order creation and rejection events.

order-service/cmd/kafkaclient · high confidence

The inventory service now includes a concrete implementation for publishing events to Kafka via the \publisher\_kafka.go\ file. This change introduces a \kafkaPublisher\ struct that wraps a \kafka.Writer\ and exposes a \Publish\ method, allowing the service to send messages with specific keys, values, and topics to Kafka.

inventory-service/internal/event · high confidence

The customer-service now exposes a new REST API to manage customer accounts and handle balance top-ups. Users can register new customers via a POST request to /api/v1/customers (accepting name and email), retrieve a list of all customers via a GET request to the same endpoint, and top up a customer's balance by sending a POST request to /api/v1/top\_up with a customer ID and amount. The service runs on a configurable HTTP port, supports CORS, and handles graceful shutdown.

customer-service/cmd/rest · high confidence

The order-service now exposes a REST interface to manage orders, introducing endpoints for creating new orders (POST /api/v1/orders) and retrieving the full list of orders (GET /api/v1/orders). This change adds the core HTTP handler logic and router configuration, including CORS support and graceful server shutdown, enabling external clients to interact with the order service via standard HTTP requests.

order-service/cmd/rest · high confidence

This change introduces the core customer domain model and its in-memory persistence layer within the customer service. The Customer entity now includes fields for ID, name, email, and balance, with validation ensuring names and emails are non-empty and emails are well-formed. It also supports a TopUp operation to increase the customer's balance. The in-memory repository provides methods to save customers (enforcing unique email constraints), retrieve all customers, find a customer by ID, and update a customer's balance, accompanied by unit tests for both the entity logic and repository operations.

customer-service/internal/customer · high confidence

The customer service now includes a main entry point (main.go) and a configuration file (config.yml) to bootstrap the application. The service starts an HTTP server on port 4002, connects to a local MySQL database using the specified DSN, and integrates with a Kafka broker at localhost:9092. It initializes an in-memory customer repository and exposes REST endpoints via the configured request handler.

customer-service/cmd · high confidence

This change introduces the core order management capabilities within the order-service, including the definition of the Order aggregate (with status transitions like Placed, Created, and Rejected), event structures for order lifecycle notifications, and an in-memory repository for storing and retrieving orders. It also adds a Kafka-based event publisher to emit order-related events, establishing the foundational infrastructure for order processing and asynchronous communication.

order-service/internal/order · high confidence

The order service is now available as a standalone application that exposes a REST API on port 4003 and processes events via a Kafka consumer. The service is configured through a new \config.yml\ file, which defines database connection parameters (MySQL) and Kafka broker settings. On startup, the application initializes an in-memory order repository, a Kafka-based event publisher, and a REST handler, running both the HTTP server and the Kafka consumer concurrently while handling graceful shutdown signals.

order-service/cmd · high confidence

The lib package introduces foundational infrastructure for the application, including a centralized configuration system using Viper that supports file-based settings with automatic environment variable fallback, a PostgreSQL database connection helper via sqlx with configurable connection pooling, custom error types (ErrBadRequest, ErrNotFound) for structured error handling, and a REST response writer that automatically maps errors to appropriate HTTP status codes.

lib · high confidence

Added an nginx-based reverse proxy to route API traffic to specific microservices. The configuration maps /api/v1/customers and /api/v1/top\_up requests to the customer service, /api/v1/orders to the order service, and /api/v1/products and /api/v1/stocks to the inventory service.

reverse-proxy · high confidence

This change establishes the foundational inventory service components within the \inventory-service/internal/inventory\ package. It adds the \Product\ entity with business logic for managing stock levels, sale prices, and average costs, alongside an \OrderItem\ struct to represent order line items. A \Stock\ type is introduced to handle stock deductions based on order items, calculating total prices. Persistence is provided by a new in-memory repository (\inMemoryRepository\) that supports saving, retrieving, and updating products, as well as checking available stock. Comprehensive unit tests are included to validate product creation, price updates, and stock operations.

inventory-service/internal/inventory · high confidence

The order service now exposes core order management capabilities through a new use-case layer. Users can place new orders via the PlaceOrder method, which persists the order and publishes an event to a Kafka topic named 'Order'. The service also handles incoming domain events to update order status (OrderRejected) and finalize pricing (OrderCreated), and provides a GetAllOrders endpoint to retrieve a list of orders with their details.

_order-service/internal/use\case · high confidence

The inventory service now exposes a REST API to manage products and stock levels. Users can retrieve all products via a GET request to /api/v1/products, create new products via POST to /api/v1/products, and add stock to existing items via POST to /api/v1/stocks. The server implementation includes CORS support and graceful shutdown handling.

inventory-service/cmd/rest · high confidence

The inventory service now exposes a use-case layer that handles product management and order processing. Users can create products, retrieve all products, and add stock to existing items. Additionally, the service processes incoming orders by validating available stock, updating inventory levels, and publishing events to indicate whether an order was accepted or rejected.

_inventory-service/internal/use\case · high confidence

The inventory service has been updated to run as a combined HTTP server and Kafka consumer. It now listens on port 4001 for REST requests and connects to Kafka at localhost:29092 to process events, replacing the previous standalone behavior. Configuration for the database, Kafka brokers, and server port is now managed via a new config.yml file in the cmd directory.

inventory-service/cmd · high confidence

The customer service now includes a new use-case layer that introduces a \CustomerService\ with a \TopUp\ method designed to prevent race conditions during balance updates by using per-customer mutexes. Additionally, a \GetAllCustomers\ function has been added to retrieve a list of all customers, returning structured \CustomerDetail\ responses that include ID, name, and balance.

_customer-service/internal/use\case · high confidence

New go.mod and go.sum files have been added for the customer-service, inventory-service, and lib modules, establishing their dependency trees. The customer-service and inventory-service modules both depend on the local lib module (v1.0.1), along with common libraries such as gorilla/mux, viper, and sqlx. The inventory-service module additionally includes segmentio/kafka-go for Kafka integration, while the lib module provides foundational dependencies including lib/pq for PostgreSQL connectivity.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 62 → 57 (-4.2)
• Rubric changed (rubric-2026.08.17 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 99 → 99 (+0.0)
• Architecture 100 → 98 (-1.8)
• Maturity 65 → 43 (-21.2)
• Readiness 47 → 47 (+0.3)
• Security 68 → 81 (+13.5)
• Domain Modelling 100 → 100 (+0.0)

• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — no supported dependency manifest was read
• Duplicated block (10 lines × 3) (customer-service/cmd/rest/router.go)
• Duplicated block (10–11 lines × 3) (customer-service/cmd/rest/router.go)
• Duplicated block (13–14 lines × 2) (inventory-service/cmd/main.go)
• Duplicated block (14 lines × 2) (inventory-service/cmd/rest/router.go)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• Low IaC: DS-0026 (customer-service/Dockerfile)
• Low IaC: DS-0026 (inventory-service/Dockerfile)
• Low IaC: DS-0026 (order-service/Dockerfile)
• No exposed public API
• Test reliability not included
• …and 1 more

• Documentation: no installation or build instructions (README.md)
• Documentation: no licence statement (README.md)
• Documentation: no usage examples (README.md)
• Duplicated block (14 lines × 2) (inventory-service/cmd/rest/router.go)
• Duplicated block (14 lines × 3) (customer-service/cmd/rest/router.go)
• Duplicated block (18–19 lines × 2) (inventory-service/cmd/main.go)
• Duplicated block (19 lines × 2) (inventory-service/internal/event/publisher_kafka.go)
• Duplicated block (6 lines × 3) (customer-service/cmd/rest/router.go)
• Duplicated block (8 lines × 2) (customer-service/cmd/rest/router.go)
• Duplicated block (8 lines × 3) (customer-service/cmd/rest/router.go)
• High CVE: [GHSA redacted] (customer-service/go.mod)
• High IaC: WD-COMPOSE-0001 (docker-compose.yml)
• High IaC: WD-COMPOSE-0002 (docker-compose.yml)
• High IaC: WD-COMPOSE-0002 (docker-compose.yml)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• …and 37 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

izharishaksa/ecommerce-system-example was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.