System Architecture

End-to-end map of the Mini's n More platform: browser, Nginx, gateway, edge proxies, catalog core, databases and external integrations.

Diagram v1.4 · Updated 04 Aug 2026, 08:10 GST— Edge → core hop documented as fixed CATALOG_BASE_URL; defunct integration service removed from the map.

100%

Rendering diagram…

Scroll to zoom · drag to pan

1 · Step-by-step workflow

Shopper or admin hits the public edge

Every request lands on Nginx :443, the only internet-facing process.
Nginx serves the TanStack Start frontend and forwards API traffic onward.

Frontend calls the gateway

The app calls /api/* and /api/v1/** against VITE_API_BASE_URL.
Nginx proxies those calls to Gateway :8080.

Gateway authenticates and routes

/api/authenticate, /api/register, /api/account/*, /oauth2/** terminate on the gateway itself.
Everything else is routed over Consul lb:// entries with the JWT relayed downstream.

Edge services proxy to the catalog core

Store :8081 handles /api/v1/** for catalog, CMS and admin.
Commerce :8082 handles orders, profile, coupons and returns.
Both rewrite /api/v1/X → /internal/v1/X and call backend over Spring RestClient.

Core executes business logic and persists

Backend :8084 owns the miniandmore Postgres database and all domain services.
Redis caches hot reads; S3/R2 stores product imagery and uploads.

External systems are called from the core

Ledgerly receives product/order pushes and returns inventory and tracking.
Razorpay handles payment creation, verification and refunds.

2 · Additional details

Services and ports

Gateway :8080 — Spring Boot 3.5 / JHipster 8.12, WebFlux, JWT issuance and routing.
Store :8081 and Commerce :8082 — stateless proxies, no datasource.
Backend catalog core :8084 — Spring Boot 4.0 / JHipster 9.0 MVC, /internal/v1/** only.
integration/ :8083 is defunct and deleted from git.

Supporting infrastructure

Consul :8500 for discovery and config; Redis :6379 via Redisson.
PostgreSQL miniandmore :5432 (backend) and gateway :5433 (R2DBC).
S3/R2-compatible object storage for images and documents.

Security boundaries

Backend binds to 127.0.0.1 in production and is never internet-reachable.
The same Bearer JWT travels end-to-end and is validated independently by each service against a shared HMAC secret.
application.internal-api-key guards every edge → core call.

Known discrepancies

Deploy scripts and PRODUCTION_READINESS.md still reference the deleted integration service.
/internal/v1/ledgerly/webhooks is not proxied by any committed Nginx config or gateway route.

3 · Advantages & usage

Advantage

Only one process is exposed to the internet, shrinking the attack surface.
Auth, CORS and rate limiting are configured once instead of per service.

Usage

All storefront and admin traffic enters here before reaching any service.
OAuth2 login with Google terminates on the gateway and issues the platform JWT.

4 · Phase 2 additions

Reachable Ledgerly webhook path

Add committed Nginx or gateway routing for /internal/v1/ledgerly/webhooks.
Keep signature verification at the core.

Deployment topology clean-up

Remove the deleted integration service from deploy scripts and readiness docs.
Align all services on one Spring Boot / JHipster generation.

Horizontal scale-out

Multiple store/commerce instances behind Consul once traffic justifies it.
Container orchestration is explicitly out of scope for Phase 1.