Multi-store commerce platform
Several storefronts had to share one stock pool and one order process.
- Client
- Independent project
- Service
- Custom platforms & apps
- Status
- Live
01 / Build
What I built
Custom TypeScript platform with queues, order verification and courier integration.
- Node.js
- TypeScript
- Fastify
- PostgreSQL
- Redis
- BullMQ
- Next.js
- Hetzner
- Cloudflare
02 / Decisions
Key decisions
- One stock pool in PostgreSQL, with stock reserved inside the same transaction that creates the order, so two storefronts can never sell the same last item.
- Slow work (order verification, courier bookings, notifications) runs in BullMQ queues on Redis. Checkout answers at once, and a courier outage delays a job instead of failing an order.
- Self-managed servers on Hetzner behind Cloudflare, so I control the whole stack and the edge handles caching and bot traffic before it reaches the API.
03 / Notes
Architecture and hindsight
Architecture
Each storefront is a Next.js front end on the same Fastify API, written in TypeScript end to end. PostgreSQL holds products, stock and orders for every store. When an order is placed, the API reserves stock and writes the order in one transaction, then hands verification, courier booking and customer messages to BullMQ workers. Failed jobs retry on their own and stay visible until they succeed.
What I'd do differently
Add an outbox table between orders and the queue from the start. Writing the job to the database in the same transaction as the order, then moving it to Redis, means a job can never be lost between the commit and the queue.
04 / Outcome
Outcome
Live in production; several storefronts sell from one stock pool through one order process.
Have a problem like this one?