Building Multi-Tenant SaaS: Domain-Based Tenant Resolution Strategies

Understanding Multi-Tenancy

Multi-tenancy is an architectural pattern where a single instance of software serves multiple customers (tenants), with each tenant's data isolated and invisible to other tenants. In the context of SaaS applications, this approach maximizes resource efficiency while maintaining strong isolation between customers.

Tenant Resolution Strategies

Before diving into domain-based approaches, let's understand the different strategies for tenant resolution and their trade-offs.

Domain-Based Architecture Implementation

Implementing domain-based tenant resolution requires careful consideration of several architectural components working together seamlessly.

CREATE TABLE domains (
  id UUID PRIMARY KEY,
  domain_name VARCHAR(255) UNIQUE NOT NULL,
  tenant_id UUID NOT NULL,
  status VARCHAR(20) DEFAULT 'pending',
  verified_at TIMESTAMP,
  created_at TIMESTAMP DEFAULT NOW(),
  
  FOREIGN KEY (tenant_id) REFERENCES tenants(id),
  INDEX idx_domain_lookup (domain_name, status)
);

// Express.js middleware example
const tenantResolver = async (req, res, next) => {
  const hostname = req.get('host');
  
  // Check cache first
  let tenant = await redis.get(`tenant:${hostname}`);
  
  if (!tenant) {
    // Lookup in database
    const domain = await Domain.findOne({
      where: { 
        domain_name: hostname, 
        status: 'verified' 
      },
      include: ['tenant']
    });
    
    if (!domain) {
      return res.status(404).json({ 
        error: 'Domain not found' 
      });
    }
    
    tenant = domain.tenant;
    
    // Cache for 5 minutes
    await redis.setex(`tenant:${hostname}`, 300, 
      JSON.stringify(tenant));
  }
  
  req.tenant = tenant;
  next();
};

Performance Optimization Strategies

Domain-based tenant resolution can introduce latency if not properly optimized. Here are key strategies to maintain high performance at scale.

Data Isolation Patterns

Once you've resolved the tenant, you need to ensure proper data isolation. Here are the main patterns for multi-tenant data architecture.

-- Every query must include tenant_id
SELECT * FROM users 
WHERE tenant_id = ? AND active = true;

-- Use Row Level Security (PostgreSQL)
CREATE POLICY tenant_isolation ON users
  USING (tenant_id = current_setting('app.tenant_id')::UUID);

-- Set schema based on tenant
SET search_path = tenant_123, public;

-- All queries automatically use tenant schema
SELECT * FROM users WHERE active = true;

// Dynamic database connection
const dbConfig = {
  host: 'localhost',
  database: `tenant_${tenant.id}`,
  user: 'app_user',
  password: process.env.DB_PASSWORD
};

const connection = await pg.connect(dbConfig);

Scaling Considerations

As your multi-tenant SaaS grows, you'll need to consider various scaling strategies to maintain performance and reliability.

Security Best Practices

Security in multi-tenant applications requires special attention to prevent data leakage and ensure proper tenant isolation.

Conclusion

Building a successful multi-tenant SaaS with domain-based tenant resolution requires careful planning of your architecture, performance optimization, and security measures. While it adds complexity compared to simpler approaches, the benefits in terms of user experience, branding flexibility, and scalability make it worthwhile for many applications.

The key is to start with a solid foundation, implement proper caching and optimization from the beginning, and plan for scale. Remember that the choice between data isolation patterns should be based on your specific requirements for security, compliance, and operational complexity.