Architecture Advice Needed – Multi-Tenant Business Platform

I'm looking for architectural feedback from experienced software engineers and architects.

Current Context

We have a business management platform used by multiple companies.

Tech stack:

• Frontend: React + Vite + Tailwind + customized Shadcn/UI

• Backend: Django + DRF

• Database: SQL Server

• Async jobs: Celery + Redis

• Storage: MinIO

• Mobile: Capacitor

• Reverse Proxy: Traefik + Nginx

The platform contains several business domains:

Collections & Finance

• Clients

• Documents

• Payments

• Unpaid invoices

• Risk management

• Validation workflows

Human Resources

• Employees

• Attendance

• Expenses

• Documents

• Commissions

• Tasks

Commercial & Sales

• Objectives

• Validation cycles

• Sales tracking

The backend is organized as a modular monolith composed of roughly 40+ Django apps.

---

How The Platform Works Today

The platform is used by several independent companies.

Each company currently has:

• Its own domain/subdomain

• Its own branding

• Its own logo

• Its own SQL Server database

• Its own ERP database integration

Example:

client-a.platform.com
client-b.platform.com
client-c.platform.com

Functionally, all companies use nearly the same application.

Differences are mostly:

• Branding

• Configuration

• Data

• ERP connection settings

---

Current Deployment Model

Today, each company has its own deployment stack.

For every company we run:

Frontend
Backend
Celery Worker
Celery Beat
Redis
Nginx

Which means:

5 companies = 5 stacks
20 companies = 20 stacks
100 companies = 100 stacks

The codebase is identical across all deployments.

Only configuration and tenant-specific settings change.

---

Current Architecture

Positive Aspects

• Clear business domains

• Modular monolith structure

• JWT authentication

• Celery background jobs

• Shared codebase

• Strong domain organization

Current Challenges

• Limited automated testing

• No mature CI/CD pipeline yet

• Operational overhead grows with every new company

• Some cross-domain dependencies remain

• Branding is deployment-specific rather than tenant-driven

---

Important Technical Constraint

Many models currently define tables like:

db_table = f"[{settings.SQL_SERVER_DB}].[dbo].[TABLE_NAME]"

The database name is resolved at application startup.

This means the application is effectively bound to a specific database when the process starts.

Serving multiple tenant databases from the same running application would require architectural changes.

---

What We Want To Achieve

Move from:

One deployment per company

To:

One shared platform
One deployment
Multiple tenant databases
Multiple ERP databases
Dynamic branding
Dynamic configuration

Conceptually:

                Platform
                    |
      --------------------------------
      |              |              |
   Client A       Client B       Client C
      |              |              |
     DB A           DB B           DB C
    ERP A          ERP B          ERP C

Goals:

• Single codebase

• Single deployment process

• Easier onboarding of new companies

• Dynamic branding based on tenant

• Strong tenant isolation

• Lower operational cost

• Ability to scale to dozens or hundreds of companies

---

Questions

1. Would you keep the modular monolith architecture or move toward microservices?

2. Would you keep a database-per-tenant model or choose another tenancy strategy?

3. What risks do you see with dynamic database routing in Django?

4. Have you implemented a similar architecture?

5. With a team of 2–5 developers, what would be your priority roadmap for the next 12 months?

6. What major architectural risks might we be underestimating?

Any feedback, criticism, alternative approaches, or real-world experiences would be greatly appreciated.

Вернуться на верх