BaanBaini_MS

BaanBaini_MS is a marketplace backend built as a Spring Boot microservices system. The project models the foundation of a commerce platform where sellers can publish products, product data is owned by a dedicated warehouse service, and platform traffic is routed through a gateway with service discovery and distributed tracing.

The goal of this project is not just to expose APIs. It demonstrates how a marketplace backend can be decomposed into independently owned services, connected through clear contracts, and monitored across service boundaries.

Product Vision

BaanBaini is designed as a multi-service commerce platform for managing marketplace operations. In the current scope, the platform focuses on seller-driven product onboarding:

• Sellers can submit product details through a seller-facing service.
• Product ownership is separated into a warehouse service responsible for persistence.
• Services register with Eureka, allowing the gateway to discover and route traffic dynamically.
• Cross-service calls are traceable through Zipkin-compatible distributed tracing.
• Shared product contracts live in a common module to keep service communication consistent.

This gives the project a realistic microservices shape: user-facing APIs, internal service ownership, gateway routing, shared contracts, service discovery, persistence, and observability.

Key Features

Seller Product Publishing

Sellers can create product listings with title, description, price, and image references. The sellers service acts as the business-facing entry point and delegates product storage to the warehouse service.

Warehouse-Owned Product Storage

Product persistence is handled by the warehouse service, backed by MongoDB. The warehouse service generates product identifiers and owns the product database boundary.

API Gateway Routing

Spring Cloud Gateway provides a single entry point for clients. Discovery-based routing keeps the gateway decoupled from hardcoded service instances and allows requests such as /sellers/products and /warehouse/products to resolve through registered services.

Service Discovery

Eureka is used as the service registry. Each service registers itself with Eureka so the system can discover services by name instead of relying only on fixed host and port configuration.

Distributed Monitoring

The gateway, sellers, and warehouse services include Micrometer/Brave/Zipkin tracing dependencies and tracing log patterns. This allows a request to be followed across the gateway, seller service, Feign client call, warehouse service, and persistence boundary.

Shared Domain Contract

The commons module contains the shared Product model and common utilities. This keeps the service contract explicit and reduces duplication across services that exchange product data.

Architecture

Client
  |
  v
Spring Cloud Gateway
  |
  |---> sellers service
  |       |
  |       v
  |    Feign client
  |       |
  |       v
  |    warehouse service
  |       |
  |       v
  |    MongoDB
  |
  `---> service discovery through Eureka

Tracing: Gateway -> Sellers -> Warehouse -> MongoDB boundary

Service Map

Service	Responsibility	Port
Gateway	Public entry point and discovery-based routing	8080
Eureka	Service registry and discovery dashboard	8761
Sellers	Seller-facing product workflow	8083
Warehouse	Product persistence and product id ownership	8081
Users	User service foundation for future account workflows	8082
Zipkin	Distributed tracing UI/server	9411

Product Flow

1. A seller submits product data.
2. The request enters through the gateway or directly through the sellers service.
3. The sellers service owns the seller-facing workflow and forwards the request using OpenFeign.
4. The warehouse service generates a product id.
5. Product data is mapped into a MongoDB document and saved.
6. The created product is returned back through the same service chain.
7. Trace ids in the logs make the request path visible across services.

Monitoring and Observability

The project includes the building blocks needed to debug a distributed request:

• Zipkin-compatible tracing configuration.
• Trace id and span id log patterns.
• Actuator dependencies on gateway, sellers, and warehouse.
• Gateway-level visibility into traffic entering the platform.
• Service-level logs for the seller and warehouse product workflow.

This is important because microservices add operational complexity. A successful request may cross multiple applications before it reaches the database, so traceability is treated as part of the architecture rather than an afterthought.

Tech Stack

• Java 17
• Spring Boot
• Spring Cloud Gateway
• Spring Cloud Netflix Eureka
• Spring Cloud OpenFeign
• Spring Data MongoDB
• Micrometer, Brave, and Zipkin
• Gradle
• Lombok
• ModelMapper

Repository Layout

BaanBaini_MS/
|-- commons/       Shared product model and utilities
|-- eureka/        Service discovery server
|-- gateway/       API gateway
|-- sellers/       Seller-facing service
|-- users/         User service foundation
|-- warehouse/     Product persistence service
|-- ZipkinServer/  Local Zipkin server JAR
|-- build.gradle
`-- settings.gradle

Running Locally

Expected local services:

• MongoDB on localhost:27017
• Eureka dashboard at http://localhost:8761
• Gateway at http://localhost:8080
• Warehouse at http://localhost:8081
• Users at http://localhost:8082
• Sellers at http://localhost:8083
• Zipkin at http://localhost:9411

Start order:

1. MongoDB
2. Eureka
3. Gateway
4. Warehouse
5. Sellers
6. Users, when needed
7. Zipkin, when tracing is needed

Start Zipkin:

java -jar ZipkinServer\src\zipkin-server-2.24.0.jar

Example product creation through the gateway:

curl -Method POST http://localhost:8080/sellers/products `
  -ContentType "application/json" `
  -Body '{"title":"Handmade Basket","description":"Woven storage basket","price":1200,"imagesUrl":["https://example.com/images/basket-1.jpg"]}'

Design Decisions

• Product persistence is owned by warehouse, not duplicated inside sellers.
• The seller workflow communicates with warehouse over HTTP using OpenFeign, keeping the service boundary explicit.
• The gateway uses service discovery so client traffic does not need to know every backend service location.
• Product ids are generated by the owning service, which keeps identity creation close to the persistence boundary.
• Observability is built into the request path with trace ids, span ids, and Zipkin integration.
• Shared models are isolated in commons to make service contracts easy to identify and evolve.

Current Scope

This repository currently focuses on the product onboarding path and microservices infrastructure. The users service is present as a foundation for future account workflows, while product image upload is prepared at the model/configuration level but not implemented end to end.

The project is best viewed as a backend architecture portfolio piece: it shows service decomposition, gateway routing, service discovery, cross-service communication, MongoDB persistence, and distributed monitoring in a compact marketplace domain.