Auqli Server
The backend of a social live-shopping marketplace — orders, payments, wallets, logistics and real-time auctions — architected and owned end to end at up to 50,000 concurrent users.
50k
concurrent users at peak
10
domain modules
3
payment & logistics providers
// stack
// architecture
Modular monolith, module-per-domain with a repository layer · MongoDB with versioned migrations · Socket.io real-time layer · Agenda job scheduling · signature-verified webhook ingestion with delivery logs and replay · Agora, FFmpeg, Smile Identity, Stripe-class payment and multi-carrier logistics integrations
// overview
A Node.js and Express platform structured as a modular monolith, with each domain owning its own routes, controllers, services and repositories behind a shared HTTP and real-time layer. I owned the backend architecture: the v2 order lifecycle and its state machine, the buyer wallet and settlement ledger, webhook infrastructure across three payment and logistics providers, and the real-time layer behind live seller broadcasts and auction bidding. Alongside the architecture I owned production — containerised deployments, CI/CD across staging and production, versioned database migrations and runtime monitoring — and set technical direction for the team, governing API evolution and running code review.
// what was built
- ·Owned the backend architecture of a social live-shopping marketplace covering orders, payments, wallets, logistics and real-time auctions, scaling it to support up to 50,000 concurrent users at peak.
- ·Designed the v2 order lifecycle end to end: the state machine and service interfaces behind multi-carrier shipping, payment capture and verification, returns, refunds and dispute resolution — with an explicit money outcome at every terminal state.
- ·Engineered webhook infrastructure spanning three payment and logistics providers, with signature verification, persisted delivery logs and replay endpoints that cut production incident diagnosis from hours to minutes.
- ·Built the real-time layer: auction bidding over WebSockets with a REST fallback, so a dropped socket on a flaky mobile network never means a lost bid, plus live-stream session management and server-side video processing for seller broadcasts.
- ·Designed and shipped the buyer wallet system covering balances, top-ups, held funds and transaction history, alongside the revenue and livestream analytics sellers use daily.
- ·Integrated identity verification (Smile Identity KYC), social sign-in, and push notification providers, and rebuilt the media pipeline with server-side image optimisation plus a backfill migration across existing assets.
- ·Owned production: containerised deployments, CI/CD across staging and production via CircleCI, runtime monitoring, and versioned database migrations through migrate-mongo.
- ·Set technical direction for the team, governed API evolution and versioning, ran code review, and coordinated releases with mobile engineers, designers and product managers.
- ·Introduced AI-assisted development workflows into day-to-day engineering, using them to accelerate delivery while holding review and testing standards unchanged.
System design
Drawn from the actual source: services, data ownership, message flow and failure paths. Drag to pan, scroll to zoom, or open any diagram fullscreen.
Marketplace backend architecture
A modular monolith organised by domain, with routes, controllers, services and repositories layered inside each module. Deliberately not microservices: one team, one deploy, clean seams where a split would go later.
// engineering notes
The decisions worth talking through
The parts of this project where the interesting work was choosing between options, not writing the code.
Why a modular monolith and not microservices
The domain decomposition is real — orders, products, sellers, buyers, live streams and admin each own their own routes, controllers, services, repositories and models. What it deliberately does not have is a network boundary between them. With one team and one deploy, distributed transactions and per-service infrastructure would have bought failure modes without buying independence. The seams are drawn where a split would eventually go, so extraction stays a refactor rather than a rewrite.
Webhooks as infrastructure, not endpoints
Three external providers, each with its own signature scheme and retry behaviour, all mutating order and money state. Treating them as ordinary route handlers makes every incident an archaeology exercise. Instead every inbound payload is signature-verified, persisted to a request log before it is processed, and replayable on demand — which is what turned "the carrier says they sent it" from a multi-hour investigation into a single query.