Skip to main content
Fabien Fouassier
Back to Writing

Multi-tenant architecture

Patterns for multi-tenant SaaS systems without sacrificing isolation or speed.

ArchitectureSaaSMulti-tenantSeptember 26, 2025·4 min readRead article
Multi-tenant architecture

Multi-tenancy enables scale without reinventing the wheel for each client. The key is enforcing isolation by design — not as an afterthought — while keeping customization flexible enough to make each tenant feel unique. This article covers patterns I've applied in production at GetGround and Richemont.

Key takeaways

  • Isolation must be a system property (operatorId on every entity), not a runtime check
  • Customization levers (branding, feature toggles) make shared platforms feel tailored
  • Automation scripts for client provisioning accelerate onboarding from weeks to days

Notes on Multi-Tenant Architectures in Practice

When I look back at projects like GetGround and my mission at Richemont, multi-tenant architecture was not an afterthought — it was a requirement from day one. Both products were designed as greenfield builds, and the core driver was white-labeling: enabling multiple enterprise clients (or, in Richemont's case, multiple luxury brands) to use the same platform while keeping branding, features, and data strictly isolated.

Why Multi-Tenant?

The business needs differed slightly but pointed to the same solution:

  • GetGround needed a platform that could be white-labeled for multiple clients — each with their own colors, logos, and feature set.
  • Richemont, as a luxury group, owns multiple "maisons" (brands). Each maison needed its own flavor of the application, but it made no sense to rebuild the entire stack per brand.

Multi-tenancy gave both organizations the ability to scale, while keeping operations lean.

Architectural Choices

  • GetGround: We implemented a shared database with operator isolation on AWS DynamoDB. Every entity carried an operatorId, ensuring strict separation between clients while keeping the operational model lightweight and cost-effective.
  • Richemont: The group relied heavily on Salesforce as a backbone. Multi-tenancy here supported multiple maisons under the same umbrella, while ensuring each brand had its own identity within a common system.

Ensuring Isolation

Isolation was enforced by design:

  • Every record in DynamoDB carried an operatorId.
  • APIs and services required the operator context to function.
  • Access controls respected operator boundaries at all levels of the stack.

This made data segregation a property of the system itself, not an afterthought.

Customization Levers

Multi-tenancy only works if each tenant can still feel unique. We enabled that at two levels:

  • Branding: colors, logos, and images were tenant-specific and could be applied dynamically.
  • Features: clients could request features to be enabled or disabled.
    • For mobile apps, toggles were applied via Firebase Remote Config.
    • For web apps, toggles were managed from the Back-Office.
    • Importantly, clients couldn't just flip features themselves. Some features came with additional costs, so enabling them required a request and approval process.

Challenges Along the Way

One of the hardest parts was migrations.

Because tenants shared the same codebase and infrastructure, a major migration required updating every client's apps. We invested in automation, but version alignment remained a coordination challenge.

Another recurring friction was infrastructure provisioning. We had scripts that could create a new client's base environment in about a minute. But they weren't fully optimized — some manual steps remained, and with more time, those scripts could have become a true one-click onboarding pipeline.

The Payoff

The benefits were clear:

  • Faster onboarding: A complete client setup — infrastructure, back-office, mobile app, and web app — could be deployed in about a week.
  • Lower costs: Shared infra and codebase reduced maintenance overhead.
  • Flexibility: Clients received tailored apps without us needing to reinvent the wheel each time.

Reflections

The system proved solid. Simplicity was a guiding principle, which made it reliable in production. If I had to improve it, I'd revisit the automation scripts: making them more comprehensive and modular would reduce human intervention and accelerate onboarding even further.

Tech at a Glance

  • AWS DynamoDB with operatorId-based isolation
  • Firebase Remote Config for mobile feature toggles
  • Custom Back-Office (React + NestJS) for web feature toggles
  • Salesforce (Richemont) for maison-level multi-tenancy
  • Infrastructure scripts for rapid client provisioning