Xây SaaS không Supabase: Backend linh hoạt để tăng trưởng

src/
  modules/
    auth/
    billing/
    teams/
    projects/
    notifications/
    files/
  shared/
    db/
    queue/
    config/
    logger/

CREATE TABLE projects (
  id UUID PRIMARY KEY,
  tenant_id UUID NOT NULL,
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX idx_projects_tenant_id ON projects (tenant_id);

{
  "error": {
    "code": "PROJECT_LIMIT_REACHED",
    "message": "Project limit reached for current plan."
  }
}

Mỗi endpoint cần:

– Validate input
– Kiểm tra auth
– Kiểm tra permission
– Gọi service
– Log event quan trọng
– Trả lỗi có code ổn định

API tốt giúp sản phẩm dễ mở rộng integration.

Auth: tự build ít nhất có thể, kiểm soát nhiều nhất cần thiết

Auth là nơi không nên “tự chế” nếu không có lý do mạnh. Không dùng Supabase Auth không nghĩa là tự viết password hashing, session, OAuth từ đầu.

Lựa chọn tốt:

– Auth0
– Clerk
– WorkOS
– Keycloak
– FusionAuth
– Ory
– Lucia/Auth.js nếu muốn code-level control

SaaS B2B cần gì?

Auth cho SaaS B2B thường cần:

– Email/password hoặc magic link
– OAuth Google/Microsoft
– Organization/team membership
– Roles/permissions
– SSO/SAML cho enterprise
– SCIM nếu bán cho công ty lớn
– Audit log

Tách rõ hai khái niệm:

– Identity: user là ai
– Authorization: user được làm gì trong tenant nào

Đừng gắn role trực tiếp vào user toàn cục nếu SaaS có nhiều workspace. Một user có thể là admin ở workspace A, viewer ở workspace B.

Background jobs: tăng trưởng bắt đầu khi request không còn đủ

Nhiều việc không nên chạy trong HTTP request:

– Gửi email
– Tạo invoice
– Xử lý file
– Đồng bộ CRM
– Gọi webhook
– Tính analytics
– Import dữ liệu
– Retry payment

Dùng queue từ sớm giúp hệ thống chịu tải tốt hơn.

API request
  -> ghi database
  -> publish event/job
  -> trả response nhanh
Worker
  -> xử lý job
  -> retry nếu lỗi
  -> log kết quả

Cần có:

– Retry với backoff
– Dead-letter queue
– Idempotency key
– Job timeout
– Dashboard quan sát job

Không có idempotency, retry có thể tạo double charge, double email, double webhook. Đây là lỗi SaaS rất đau.

File storage: abstraction nhỏ, lợi ích lớn

Đừng để code gọi trực tiếp provider khắp nơi. Tạo interface:

interface StorageService {
  upload(path: string, body: Buffer): Promise<string>;
  getSignedUrl(path: string): Promise<string>;
  delete(path: string): Promise<void>;
}

Sau đó dùng S3, R2, GCS, Azure Blob hoặc MinIO phía sau. Khi cần đổi provider, chỉ đổi adapter.

Quy tắc:

– Không lưu file binary trong database
– Lưu metadata trong Postgres
– Dùng signed URL cho file private
– Quét virus nếu khách upload file nhạy cảm
– Tách bucket theo environment

Observability: không đo, không tăng trưởng

SaaS chết không chỉ vì bug. SaaS chết vì không biết bug nằm đâu.

Tối thiểu cần:

– Structured logs
– Request ID xuyên suốt API và worker
– Error tracking bằng Sentry
– Metrics: latency, error rate, queue depth, DB connection
– Tracing cho flow phức tạp
– Audit log cho hành động nhạy cảm

Log nên có context:

{
  "requestId": "req_123",
  "tenantId": "tenant_456",
  "userId": "user_789",
  "action": "project.create"
}

Khi khách báo lỗi, đội support cần tìm được sự kiện trong vài phút, không phải vài giờ.

Deployment: bắt đầu đơn giản, chuẩn bị đường lớn

Không cần Kubernetes từ ngày đầu. Nhiều SaaS chạy tốt với:

– Docker image
– Managed Postgres
– Managed Redis
– Object storage
– One API service
– One worker service
– CI/CD tự động

Khi traffic tăng, scale theo lớp:

1. Tăng instance API
2. Tăng worker riêng theo queue
3. Tối ưu index và query
4. Thêm read replica
5. Tách service nặng
6. Dùng cache có chiến lược
7. Multi-region nếu cần

Quan trọng: backend phải stateless ở API layer. Session lưu trong cookie/JWT hoặc Redis, file lưu object storage, job lưu queue. Như vậy horizontal scale dễ hơn.

Billing và entitlement: đừng để thành if-else khắp code

SaaS nào cũng sẽ có plan, quota, trial, add-on, overage. Nếu rải logic kiểu:

if (user.plan === "pro") ...

… code sẽ nát nhanh.

Nên có service riêng:

EntitlementService.canCreateProject(tenantId)
EntitlementService.canInviteMember(tenantId)
EntitlementService.getLimit(tenantId, "projects")

Billing provider như Stripe chỉ là nguồn thanh toán. Product entitlement nên nằm trong hệ thống riêng, đồng bộ từ Stripe webhook.

Cần xử lý:

– Webhook retry
– Payment failed
– Subscription cancelled
– Trial expired
– Plan changed
– Invoice paid
– Grace period

Billing sai ảnh hưởng doanh thu trực tiếp.

Kết luận: không dùng Supabase để có quyền chọn

Supabase rất tốt cho nhiều dự án. Nhưng với SaaS cần tăng trưởng dài hạn, backend tự chủ cho nhiều quyền hơn: quyền tối ưu, quyền thay provider, quyền thiết kế domain sâu, quyền đáp ứng enterprise, quyền debug rõ.

Kiến trúc khuyến nghị:

– Postgres làm lõi dữ liệu
– API rõ contract
– Auth dùng provider chuyên biệt hoặc self-hosted chuẩn
– Queue cho việc nền
– S3-compatible storage qua abstraction
– Observability từ sớm
– Multi-tenancy thiết kế ngay ngày đầu
– Billing/entitlement tách riêng
– Deployment đơn giản nhưng stateless

Không cần build phức tạp ngay. Cần build đúng điểm nối. SaaS tăng trưởng không thắng nhờ backend “ngầu”. Thắng nhờ backend dễ hiểu, dễ sửa, dễ mở rộng, ít khóa chặt.