cd ../projects
Backend · Multi-tenant SaaS·2025·public repository·repo: B2B-SaaS-Platoform

B2B SaaS Platform

Production-ready multi-tenant backend architecture

view source

// illustrative mock, real screenshots coming soon

A scalable, multi-tenant B2B SaaS backend built with FastAPI, PostgreSQL, and Docker, designed for tenant isolation, role management, and asynchronous integration with external systems.

$ cat problem.md

Multi-tenant SaaS needs hard data isolation, flexible roles, and resilient external integrations from day one, bolting them on later is painful.

$ whoami --role

Design & build (solo)

  • FastAPI
  • PostgreSQL
  • Docker

$ cat approach.md

  1. 01Tenant data isolation as a core architectural constraint
  2. 02Role-based access control for users within tenants
  3. 03External API integrations with asynchronous webhook processing
  4. 04Containerized, cloud-ready, and built for extensibility

$ ls highlights/

› Tenant data isolation
› Role-based access control
› Async webhook processing
› Cloud-ready & extensible

$ cat api.md

PostgreSQL · schema-per-tenant · SQLAlchemy 2.0 async·auth: RBAC roles · admin · staff · member

The public repo is this platform's backend architecture and data layer — the multi-tenant schema below, with the HTTP surface kept in a private deployment. Tenant isolation, RBAC, audit logging, idempotent webhooks, and integration health are designed in from day one.

// Tables reproduced from the repo's SQLAlchemy ORM models; relationships shown as foreign keys.

Identity & tenancy

TABLE

tenants

An isolated customer org, mapped to its own DB schema.

  • id: UUID
  • company_name: str · unique
  • schema_name: str · unique
  • subscription_status: trial | active | cancelled
TABLE

users

A global user identity.

  • id: UUID
  • email: str · unique
  • password: str · hashed
  • is_active: bool
  • last_login: datetime?
TABLE

user_tenants

Binds a user to a tenant with a role (RBAC).

  • user_id → users.id
  • tenant_id → tenants.id
  • role: admin | staff | member

Reliability & integrations

TABLE

audit_logs

Immutable record of every create / update / delete.

  • tenant_id, user_id
  • action · table_name · record_id
  • payload: JSON
TABLE

idempotency_keys

De-dupes webhooks and external calls so retries are safe.

  • key: str · unique
  • tenant_id → tenants.id
TABLE

integration_status

Per-tenant health of each third-party integration.

  • service_name: str
  • last_success / last_failure: datetime
  • failure_count: int

Client workflows · tenant schema

TABLE

clients

A tenant's own end customer.

  • id: UUID
  • name, email · unique
  • phone?, address?
  • is_active: bool
TABLE

workflows · workflow_steps

Named, ordered steps a client moves through.

  • workflow → steps (ordered)
  • step_name · step_order
TABLE

clients_workflow_progress

Tracks where each client is in a workflow.

  • client_id, workflow_id
  • current_step: int
  • is_completed: bool
TABLE

communications

Logged client touchpoints (email / call / meeting).

  • event_type, status
  • external_message_id?
view source on GitHub