The Orders service orchestrates the checkout process for Shop Microservers. When a user places an order, this service acts as the transaction coordinator: it fetches the user’s cart, decrements stock for each item in the catalog, persists a new order record in PostgreSQL, and clears the cart — all in sequence. It also provides endpoints to retrieve order history and individual order details, each scoped to the authenticated user. Because it depends on both the cart and catalog services, it communicates with them over Docker’s internal network rather than going through the public gateway.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/astrxnomo/shop-microservers/llms.txt
Use this file to discover all available pages before exploring further.
Overview
Runtime
Express on port 3003 inside Docker. Gateway prefix:
/api/orders/.Database
PostgreSQL — database name
orders_db. Schema managed by Prisma.Authentication
All endpoints require a valid JWT Bearer token. Orders are strictly user-scoped.
Internal Clients
Calls catalog at
http://catalog:3001 and cart at http://cart:3002 over Docker’s internal network.Endpoints
| Method | Path | Auth | Description |
|---|---|---|---|
| GET | / | Required | List all orders for the authenticated user |
| GET | /:id | Required | Get a single order by ID |
| POST | / | Required | Checkout: convert cart into an order |
All Orders endpoints are reachable through the gateway at
/api/orders/. The JWT must be included in the Authorization: Bearer <token> header on every request.Checkout Flow
Placing an order (POST /) triggers a multi-step sequence that spans three services:
Fetch the cart
The orders service calls
GET / on the cart service, forwarding the user’s JWT so the cart service can identify the user.Validate cart is not empty
If the cart contains no items, a
400 Bad Request is returned immediately and no stock is modified.Decrement stock for each item
For every item in the cart, the service calls
PATCH /products/:id/stock on the catalog service with { decrement: quantity }. If any product has insufficient stock, the catalog returns 409 and the checkout fails.Persist the order
A new
Order record is created in orders_db with all line items embedded as OrderItem records and the total carried over from the cart.Clear the cart
After the order is saved, the service calls
DELETE / on the cart service to empty the user’s Redis cart.Internal Service Clients
The orders service communicates with the catalog and cart services using lightweightfetch-based clients:
Cart client (src/clients/cart.client.ts):
src/clients/catalog.client.ts):
| Client Variable | Docker Internal Address |
|---|---|
config.cartUrl | http://cart:3002 |
config.catalogUrl | http://catalog:3001 |
Data Model
PENDING. Status transitions are not managed by the API in the current implementation — they can be updated directly in the database or via a future admin service.
User Scoping
All order queries include auserId filter derived from the JWT sub claim. This means a user can never read or interact with another user’s orders:
Response Shape
GET /, the data field is an array of Order objects, ordered by createdAt descending.
Error Cases
| HTTP Status | Condition |
|---|---|
400 | Cart is empty at checkout time |
401 | Missing or invalid JWT |
404 | Order ID not found, or order does not belong to the authenticated user |
409 | A product in the cart has insufficient stock (proxied from catalog) |
502 | Upstream call to cart or catalog service failed |
API Reference
GET /
List all orders for the current user.
GET /:id
Get a single order by ID.
POST /
Checkout and place a new order.