An order moves through six customer-facing states: pending-payment → assignment-running → in-progress → completed (happy path); manual-assignment-required and failed are escape hatches. The DB carries three additional legacy/admin statuses (paid, cancelled, disputed) with explicit transition guards. Allowed-transition map is enforced server-side; unpaid cancelled sessions never enter the failure track. Audit events are written for every transition, with an actorKind tag (system / customer / staff).
- pending-payment — Stripe Checkout session created.
- assignment-running — payment confirmed, engine cycling eligible boosters.
- manual-assignment-required — all rounds exhausted, admin steps in.
- in-progress — booster accepted, anonymous Discord room live.
- completed — delivery verified, ledger entry recorded, room archived.
- failed — post-payment fulfilment failure, compensation path attached.
- Deep dive · 01
System architecture
Four apps, one monorepo, typed end-to-end. Six services in compose; a shared contracts package as source of truth.
- Deep dive · 03
Eligibility-aware auto-assign
Two groups, two rounds each. Per-booster game / service / rank / max-order-value caps. 30-min default timer.
- Deep dive · 04
Anonymous Discord ops rooms
Discord is the ops UI. Per-order private channels named from a UUID hex. Reaction-driven ratings. Discord-as-admin-console.
- Deep dive · 05
Stripe pricing parity + rewards
Shared pricing module so FE / BE / Stripe agree to the cent. 3% processor fee as a transparent line item.
- Deep dive · 06
Operator console + live SSE
Calm, keyboard-first, audit-first. Real-time updates via Redis pub/sub → SSE; engine pause / resume / start as first-class controls.
Got something
this size?
Big ambitions, we match the energy. Drop a brief — reply within one working day.