Scalability

Built for growth, not over-engineered. SEKEN's architecture is designed to handle launch volume comfortably and scale incrementally as transaction volume grows. This page maps what scales naturally and what needs investment at each growth tier.

Growth tiers

What scales naturally

These parts of the architecture handle 100x growth without redesign:

Component	Why it scales
NestJS containers (Dokploy + DOCR)	Stateless HTTP, horizontally scalable — add container replicas per load
External Postgres (Supavisor pooler)	Vertical + read replica options; connection pooling already in place
Vite SPA (nginx container)	Static assets, cache-friendly, CDN-frontable
Xendit + Biteship + Resend	Partner SaaS, scales with us
RLS policies	Enforced per-row, no scaling concern
Domain-driven architecture	Add new bounded contexts without disrupting existing

What needs investment by tier

Tier 1, Launch (0-1k transactions/month)

State: Where we are now.

Concern	Status	Action
Search performance	✅ Adequate	Postgres + simple filters
Image storage	✅ Adequate	DigitalOcean Spaces + imgproxy
Notification volume	✅ Adequate	Per-event Resend sends
Database size	✅ Adequate	Single Postgres instance
Ops staffing	✅ Manageable	Founders + 1-2 ops staff

Tier 2, Validation (1k-10k transactions/month)

State: Post-launch product-market fit validation.

Concern	Action needed
Search relevance	Move from LIKE filters to full-text search (Postgres tsvector)
Image delivery	Add image CDN (Cloudflare or similar)
Email volume	Batch sends, bounce handling
Database queries	Add read replicas for analytics queries
Ops staffing	3-5 ops staff, structured workflows

Triggers for upgrade:

• Search response time > 500ms
• Image load time > 1s
• Email delivery rate drops below 98%
• Database CPU > 60% sustained

Tier 3, Scale (10k-100k transactions/month)

State: Substantial market presence.

Concern	Action needed
Search infrastructure	Move to Algolia or self-hosted Meilisearch
Recommendation engine	Real ML pipeline for SekenPulse
Database sharding	Consider partitioning large tables (orders, listings)
Caching layer	Redis for hot data (popular listings, seller profiles)
Notification system	Dedicated queue (Inngest or Trigger.dev)
Dispute volume	AI-assisted resolution to keep ops manageable
Cuan separation	Move finance to dedicated repo + team

Triggers for upgrade:

• Search response time > 200ms even with tsvector
• Database connection pool exhausted
• Notification delivery delay > 1 minute
• Dispute resolution backlog > 24 hours

Tier 4, Maturity (100k+ transactions/month)

State: Major Indonesian marketplace.

Concern	Action needed
Multi-region deployment	Consider Singapore + Jakarta edge regions
Custom payment infrastructure	Direct bank integrations alongside Xendit
Logistics partnerships	Direct courier integrations beyond Biteship
Data warehouse	Separate analytical store from transactional
ML infrastructure	Dedicated team for personalization, fraud, pricing
International expansion	Multi-currency, multi-language architecture

Database scaling plan

Search scaling

The single biggest scalability concern. Current implementation uses Postgres LIKE filters, adequate for launch, won't scale.

Tier	Approach	Limit
1	LIKE + Postgres indexes	~10k listings
2	tsvector full-text search	~100k listings
3	Algolia or Meilisearch	~10M listings
4	Custom search infrastructure	Unlimited

Migration path: Build search abstraction now (SearchPort) so swapping implementations is trivial.

Cuan portal scaling

Current state: live NestJS service on Dokploy with its own auth and outbox delivery. The Tier 1 refactor from a single-file Supabase deployment is complete.

Tier 3 separation:

• Move to dedicated team ownership
• Hire dedicated finance team
• Real Xero pipeline (not boolean)
• AI bot for finance queries

See Cuan Portal for detailed plan.

Ops portal scaling

Currently 100% built (52 of 52 modules). Will scale by:

Tier 2:

• Add bulk action capabilities (moderate 50 listings at once)
• Improve queue prioritization (high-value disputes first)
• Better filtering and saved views

Tier 3:

• Role specialization (KTP team, dispute team, support team)
• Workflow automation (auto-assign by category)
• AI-assisted decision making

Tier 4:

• Multi-region ops teams
• 24/7 coverage rotation
• Specialized tooling per region

Team scaling

Tier	Team composition
1	2 founders + 1-2 ops + 1 social media
2	+ 1 product designer + 2-3 ops + 1 marketing
3	+ 1 ML engineer + dedicated finance team + 5-10 ops
4	+ multiple specialized teams across regions

Strategic principles

1. Don't pre-optimize

Build for the next tier, not three tiers ahead. Premature scaling wastes runway.

2. Measure before optimizing

Every scaling decision should be triggered by a measured metric, not a hunch.

3. Buy before build

SaaS partners (Algolia, Inngest, Sentry) scale faster than in-house infrastructure. Buy until cost or control demands building.

4. Decouple before scaling

Hard to scale a monolith. Build clear boundaries (DDD bounded contexts) so individual concerns can scale independently.

5. Ops cost is people cost

The biggest scaling concern is ops staff. Every automation that reduces ops time is leverage. See Automation Roadmap.

Risks at scale

Risk	Mitigation
Search degradation	Build search abstraction now, migrate when needed
Database lock contention	Optimistic locking already in place, monitor wait events
Webhook delivery delays	OutboxProcessor + retry logic
Fraud at scale	Build fraud detection early, scale ML investment with growth
Single-team bottleneck	Hire ahead of curve, especially ops

Open questions

Question	When to decide
Algolia vs self-hosted search	Tier 2 trigger
Multi-region deployment	Tier 4 trigger
Custom payment infrastructure	Tier 3-4
ML platform investment	Tier 3

---

End of architecture documentation.

For questions, contact the Founder or refer to Pasarseken-AI-Brain for the canonical source of truth.

This documentation is verified as of 2026-07-07 and regenerated weekly from the brain.