Architecture
Strategic blueprint for Pasar Seken. This is the canonical reference for how SEKEN works as a system, from the moment a buyer opens the app to the moment a seller receives their disbursement. Every flow, every integration, every permission model is documented here.
This architecture is verified against the codebase as of 2026-07-07. Each element carries a status flag so you always know what is built versus planned. The brain regenerates this section weekly.
What this is
Premium internal documentation that serves three audiences simultaneously:
| Audience | What they get |
|---|---|
| Founders | Strategic visibility into how the business operates technically |
| Engineers | Authoritative reference for every flow, state, and integration |
| New team members | Onboarding ground truth, read this first |
Status legend
Every diagram, table, and module in this section uses the same four-state flag:
| Flag | Meaning |
|---|---|
| ✅ Live | Fully implemented, in production, verified by audit |
| 🟡 Partial | Built but incomplete, missing edge cases, or placeholder logic |
| 🔵 Planned | Designed and documented, not yet built |
| ❌ Drift | Was documented one way, codebase shows another, needs reconciliation |
How to read this section
The 18 pages are ordered by zoom level, start wide, narrow as you go.
At a glance
Three principles guiding the architecture
1. Sellers always free, forever
Zero commission on sellers is a permanent business decision, type-enforced at the database layer. Revenue comes from buyer-side fees, shipping markup, and Boost products, never from seller commissions.
2. Brain is source of truth
Every architectural decision lives in Pasarseken-AI-Brain first, then propagates to code via CLAUDE.md. This document is generated from the brain, not maintained by hand.
3. Reliability before features
The platform runs on a hardened reliability layer: idempotency guards, transactional outbox processing every 15 minutes, circuit breakers on every external integration, and optimistic locking on all order state transitions.
Key facts
| Metric | Value |
|---|---|
| Database tables | 81 |
| Order states | 14 (DB CHECK constraint enforced) |
| External integrations | 6 |
| Subdomains | 5 |
| Ops portal modules | 52 of 52 (100% built) |
| AI bots live | 2 (help center, ops staff) |
| Auto-confirm window | 48 hours |
| Return window | 24 hours |
| Backend runtime | NestJS 10 + Fastify + Drizzle (Dokploy VPS) |
| Image storage | DigitalOcean Spaces + imgproxy |
Open architectural questions
Items still under review or pending the Engineer's investigation. Each links to its detailed page.
| Question | Owner | Page |
|---|---|---|
Should fin_* tables migrate to a finances schema? | Engineer | Database Schema |
| Reverse Biteship label, v1 build scope confirmed | Engineer | Returns & Disputes |
| Algolia vs self-hosted search (Tier 2 trigger) | Engineer | Scalability |
How to use this with AI tools
Both Cursor (Founder) and Copilot (Engineer) read CLAUDE.md in the pasarseken repo, which references the brain. When working in a Claude Code session, this entire architecture is available as context, just ask.
Example prompts that work well:
- "Walk me through the checkout flow with current code references"
- "What changes if I add a new order state?"
- "Show me the money flow with all current fees"
- "What's the difference between dispute and return flows?"
Next: System Architecture →