How rifatbond007/ecommerce-microservices-platform works
1. This repo is a microservices e-commerce platform, not a single backend. The main request path is: React/Vite frontend → API Gateway → one of the domain services → that service’s own database/schema. Supporting infrastructure is PostgreSQL, Redis, and RabbitMQ.
2. The frontend is a client-side SPA under frontend/. It is organized by route-level pages for public browsing, auth, user account flows, seller/admin consoles, checkout, search, notifications, and static content. Shared UI lives in components/ui, page chrome in components/layout, and state is kept in small client stores for auth and cart. The frontend talks to the backend through src/lib/api.ts.
3. The API Gateway (services/gateway) is the primary entry point on port 3000. Its role is request routing plus cross-cutting concerns: auth enforcement, rate limiting, and shared Redis usage. It is the boundary that keeps the frontend from calling individual services directly in normal operation.
4. The backend is split into ten Express + TypeScript services, each with its own Prisma schema and its own bounded domain:
- auth: registration, login, refresh/logout, password reset, email verification, session/token handling
- user: profiles, addresses, wishlists, reviews
- product: catalog, brands, categories, inventory, variants, warehouses
- cart: carts and saved carts
- order: order lifecycle and history
- payment: payment transactions, refunds, webhook handling
- notification: user preferences and notifications delivery
- search: search index and search queries
- admin: dashboard, admin operations, settings, administrative user/order/product views
5. Each service follows the same internal layering: app.ts bootstraps the server, routes/ assembles endpoints, modules/ contains feature-specific controller/service/validator code, repositories/ owns database access through Prisma, and middleware/ handles auth/error/rate-limit concerns. This is a clear separation between HTTP, business logic, and persistence.
6. Data ownership is per service, not shared through one central application database. The README and Prisma layouts indicate a database-per-service strategy with separate schemas such as auth, product_service, cart_service, order_service, etc. That makes each domain independently deployable and reduces coupling at the storage layer.
7. RabbitMQ is the main asynchronous integration point. It is explicitly present in the notification, payment, and search services, and the infrastructure layer provisions RabbitMQ definitions. That suggests event-driven side effects such as payment notifications, search index updates, and other background workflows rather than direct synchronous coupling for every action.
8. Redis is used as shared fast-state infrastructure. In the gateway it supports edge concerns like rate limiting and possibly request/session coordination. It appears as a shared runtime dependency rather than a domain datastore.
9. The infrastructure folder is fully container-oriented. infra/docker-compose.yml orchestrates local development, with PostgreSQL initialization scripts, RabbitMQ definitions, and Redis configuration. This is the environment boundary for running the whole platform locally.
10. Security and access control are layered. JWT-based auth is centralized in the auth service, but auth middleware exists across services to protect their own endpoints. The gateway also applies auth and rate-limiting before requests reach downstream services.
11. The frontend mirrors the backend’s domain split in its UI structure. It has separate areas for customer, seller, and admin workflows, which is useful for an architecture diagram because it shows a single SPA serving multiple personas while still delegating all business operations to backend services.
12. CI/test automation exists but is secondary to runtime architecture. There is a GitHub Actions workflow, service-level Jest tests, and a shell script for API testing. The important architectural takeaway is that each service is independently testable and containerizable, matching the microservice boundaries.
Main entry points: router.service.ts Router · init-schemas.sql PostgreSQL · docker-compose.yml Compose stack · app.ts Gateway
Components 21
Frontend SPA
Client-side React/Vite interface for customer, seller, and admin workflows.
- SPA · Single-page frontend entry and routing shell.
frontend/src/app/App.tsx - Route pages · Public browsing, auth, account, checkout, search, seller, and admin pages.
frontend/src/app/pages - Shared UI · Reusable chrome and UI primitives used across the SPA.
frontend/src/components - Client state · Small client stores for auth and cart state.
frontend/src/store - API client · Frontend backend adapter used by the SPA to reach the platform.
frontend/src/lib/api.ts
API Edge
Primary request boundary and cross-cutting gateway concerns.
- Gateway · Primary entry point for routing, auth enforcement, rate limiting, and shared Redis access.
services/gateway/src/app.ts - Router · Dispatches incoming requests toward downstream services.
services/gateway/src/modules/router/router.service.ts - Edge middleware · Cross-cutting gateway controls for authentication and throttling.
services/gateway/src/middleware - Redis cache · Gateway-side fast state used for shared edge concerns.
services/gateway/src/shared/redis/redis.client.ts
Domain Services
Independently deployable Express + TypeScript services with their own Prisma-backed data ownership.
- Auth · Registration, login, sessions, password reset, and email verification.
services/auth/src/app.ts - User · Profiles, addresses, wishlists, reviews, and seller-facing user data.
services/user/src/app.ts - Product · Catalog, brands, categories, inventory, variants, and warehouses.
services/product/src/app.ts - Cart · Active carts and saved carts.
services/cart/src/app.ts - Order · Order lifecycle and order history.
services/order/src/app.ts - Payment · Transactions, refunds, and webhook handling.
services/payment/src/app.ts - Notification · User preferences and notification delivery.
services/notification/src/app.ts - Search · Search queries and search index operations.
services/search/src/app.ts - Admin · Administrative dashboards, operations, and management views.
services/admin/src/app.ts
Infrastructure
Shared platform dependencies and local container orchestration.
- PostgreSQL · Database-per-service persistence with separate schemas owned by each service.
infra/postgres/init-scripts/init-schemas.sql - RabbitMQ · Asynchronous integration backbone for payments, notifications, and search workflows.
infra/rabbitmq/definitions.json - Compose stack · Container-oriented local environment for the full platform.
infra/docker-compose.yml
Connections 32
- Route pages → API client: calls · UI flows use the shared API adapter for backend access.
- Client state → API client: syncs · Auth and cart state coordinate with backend requests.
- Shared UI → Route pages: supports · Shared layout and primitives support route-level screens.
- SPA → Route pages: renders · SPA routes the user into domain-specific pages.
- API client → Gateway: requests · Normal frontend traffic goes through the gateway instead of directly to services.
- Router → Auth: routes · Authentication flows are one of the primary downstream paths.
- Router → User: routes · User/account flows are routed to the user service.
- Router → Product: routes · Catalog and browsing requests flow to product.
- Router → Cart: routes · Cart operations route to the cart service.
- Router → Order: routes · Order lifecycle requests route to order.
- Router → Payment: routes · Payment requests route to payment.
- Router → Notification: routes · Notification endpoints route to notification.
- Router → Search: routes · Search requests route to search.
- Router → Admin: routes · Admin console requests route to admin.
- Edge middleware → Gateway: guards · Gateway applies shared auth and rate limiting before downstream access.
- Gateway → Redis cache: uses · Shared edge state is stored in Redis.
- Auth → PostgreSQL: owns schema · Auth persists sessions and identity data in its own schema.
- User → PostgreSQL: owns schema · User domain persists profiles and related data in its own schema.
- Product → PostgreSQL: owns schema · Product catalog data is stored in a dedicated schema.
- Cart → PostgreSQL: owns schema · Cart state is persisted separately from other domains.
- Order → PostgreSQL: owns schema · Order history and lifecycle data are isolated in their own schema.
- Payment → PostgreSQL: owns schema · Payment transactions and refunds are stored in a dedicated schema.
- Notification → PostgreSQL: owns schema · Notification preferences and delivery records use their own schema.
- Search → PostgreSQL: owns schema · Search metadata and logs are persisted separately.
- Admin → PostgreSQL: owns schema · Admin data and operational records use a service-specific schema.
- Payment → RabbitMQ: publishes · Payment events feed asynchronous workflows.
- Notification → RabbitMQ: consumes · Notification delivery is event-driven.
- Search → RabbitMQ: consumes · Search indexing reacts to upstream events.
- Compose stack → Gateway: orchestrates · Local compose stack brings up the platform services.
- Compose stack → PostgreSQL: orchestrates · Compose provisions the shared database platform.
- Compose stack → RabbitMQ: orchestrates · Compose provisions the event bus.
- Compose stack → Redis cache: orchestrates · Compose provisions Redis for shared fast state.