Instance per Client as Isolation Strategy
Loyaltify is a white-label loyalty platform aimed at restaurant chains. One of its architectural pillars is client isolation — each chain has its own deployment, dedicated infrastructure, and isolated database. In this case study, we explore why we didn't structure it as traditional multi-tenant and how this decision impacts predictability, compliance, and operation in scalable B2B platforms.
The Problem: Multi-tenant vs. Structural Isolation
The Loyaltify Context
From the start, Loyaltify was conceived to be deployed by different restaurant chains, each with its own technical and regulatory requirements.
In traditional SaaS models, the multi-tenant approach is common:
- ✅ Single application
- ✅ Single database
- ✅ Identification by
tenant_id - ✅ Infrastructure sharing
However, the product reality required another analysis.
B2B Client Requirements
Each restaurant chain could demand:
- ❗ Complete data isolation (no logical sharing)
- ❗ Dedicated infrastructure (predictable performance)
- ❗ Specific compliance requirements (GDPR, local regulations)
- ❗ Different robustness levels (multi-AZ databases for enterprise clients)
- ❗ Custom retention and storage policies
The architecture needed to accommodate variations without creating invisible dependencies between clients.
The Solution: Instance per Client
Loyaltify was structured with dedicated instance per client. Each chain has:
- 🔒 Its own application deployment (dedicated EC2)
- 🔒 Its own database (dedicated or isolated RDS)
- 🔒 Its own configurable environment (variables, AWS resources)
There is no logical data sharing between clients. This choice transforms infrastructure into an explicit part of the contractual strategy.
Implementation: Technical Implications
1. Impact Containment
Critical benefit: Failures are contained.
If there occurs:
- ❌ A configuration error
- ❌ An unexpected usage spike
- ❌ An infrastructure problem
→ Impact is restricted to that client.
Other chains continue operating normally. This reduces systemic risk and facilitates diagnosis.
2. Compliance and Jurisdiction
The ability to configure:
- 🔐 Dedicated RDS per region
- 🔐 Multi-AZ for high availability
- 🔐 Specific storage policies
- 🔐 Customizable backup and retention
Allows meeting different regulatory requirements without altering the application core.
Compliance doesn't depend on shared logic — it depends on that client's environment configuration.
3. Performance Predictability
In multi-tenant environments, different clients compete for the same resources (CPU, memory, I/O).
With dedicated instance:
- ✅ CPU, memory, and I/O are predictable
- ✅ Sizing is done by usage profile
- ✅ Application behavior doesn't suffer external interference
Infrastructure stops being an invisible variable.
4. Commercial Flexibility
Smaller clients can use:
- 💰 Isolated databases within the same RDS instance (economy)
Larger clients can opt for:
- 💎 100% dedicated infrastructure
- 💎 High availability (multi-AZ)
- 💎 Robust enterprise configurations
Architecture allows this variation without system restructuring.
Impact and Measurable Results
The instance-per-client strategy allowed Loyaltify to:
- ✅ Scale deployments in controlled manner — 5 active chains without sharing infrastructure
- ✅ Maintain isolation between chains — zero risk of data leakage
- ✅ Adapt infrastructure per requirement — enterprise clients with multi-AZ
- ✅ Avoid additional domain complexity — no tenant_id logic
- ✅ Offer differentiated SLA — individual contracts per service level
Isolation is not just logical. It's structural.
Relevant Technical Decisions
1. Why not shared multi-tenant?
Analyzed trade-off:
| Aspect | Multi-tenant | Instance per Client |
|---|---|---|
| Initial cost | Lower | Higher |
| Isolation | Logical | Structural |
| Compliance | Complex | Simple |
| Performance | Variable | Predictable |
| Systemic risk | High | Contained |
Conclusion: For B2B with compliance and SLA requirements, structural isolation wins.
2. How to manage multiple instances?
Automation is critical:
- Bash scripts for repeatable provisioning
- Infrastructure as code (standardized configuration)
- Centralized monitoring (CloudWatch)
3. How to price dedicated instance?
Pricing model:
- Base: Infrastructure cost + margin
- Upgrade: Multi-AZ, additional storage, performance tuning
- SLA: Differentiation by availability level
Architectural Learnings
Multi-tenant maximizes user density. Instance per client maximizes control and predictability.
Applied principles:
-
Structural isolation for B2B
- Enterprise clients require physical separation
-
Compliance simplified by design
- Each client in its own infrastructure
-
Commercial flexibility via configuration
- Not via code, but via environment
When to apply instance per client?
This architecture is appropriate when:
- You sell to B2B clients with compliance requirements
- Isolation is contractual requirement, not optional
- Differentiated SLA per client is part of business model
- Infrastructure cost can be passed to client
When NOT to apply:
- SaaS product with millions of individual users
- Startups in validation phase with limited budget
- Revenue model based on volume, not value
Strategic Conclusion
Loyaltify demonstrates that architecture should follow business model and contractual requirements, not technical dogma.
By choosing instance per client, we created a structure that:
- Meets compliance naturally (structural isolation)
- Offers predictability (dedicated performance)
- Allows commercial flexibility (differentiated configurations)
- Reduces code complexity (no multi-tenancy logic)
In Loyaltify's context — aimed at specific chains with regulatory requirements — structural isolation brought more clarity than shared infrastructure economy.
"In Loyaltify, the dominant criterion was not to concentrate the maximum number of users in a single application. It was to guarantee isolation, contractual clarity, and adaptation capacity."
Continue Exploring
If you're designing white-label or B2B platforms:
- Replicable Architecture with Strategic Decoupling — the complete Loyaltify context
- Hierarchical Modeling for Restaurant Chains — how to structure complex domains
Need consulting for white-label architecture? Learn about our services.