Managing Multiple Brands in Rails: Multi-Tenant Patterns from RobinReach

Source: Dev.to

The Challenge: Multi‑Brand Management

Imagine a user managing three different companies on your platform. Each company has:

• Its own social media profiles
• Scheduled posts
• Team members and roles
• Analytics and performance data

Without proper isolation, cross‑tenant data leaks become a nightmare. Multi‑tenancy is not just a database pattern; it’s a mindset for every layer of your application.

Workspace‑Based Multi‑Tenancy

At RobinReach, we modeled each brand or workspace as a tenant. All core models—Post, SocialProfile, Member—are scoped to a tenant. We use a thread‑safe Current object to hold the tenant context:

# app/models/current.rb
class Current < ActiveSupport::CurrentAttributes
  attribute :company
end

This allows every model to reference the current tenant easily:

# app/models/post.rb
class Post < ApplicationRecord
  belongs_to :company
  default_scope { where(company_id: Current.company.id) }
end

With this pattern, every query automatically respects tenant boundaries.

Seamless Workspace Switching

Users expect to switch between workspaces without logging out. We store the current workspace in the session:

def switch_workspace(company_id)
  session[:current_company_id] = company_id
  Current.company = Company.find(company_id)
end

Now actions such as viewing posts, scheduling content, or managing members are always scoped to the selected workspace.

Background Jobs in a Multi‑Tenant Environment

Multi‑tenancy isn’t limited to database queries; background jobs must also respect tenant boundaries.

Lessons Learned

• Always pass the tenant ID to background jobs.
• Make jobs idempotent to prevent cross‑tenant side effects.
• Use Sidekiq queues strategically; high‑volume tenants might need separate queues.

Best Practices for Workspace Multi‑Tenancy

• Enforce tenant isolation at all layers – models, services, jobs, and controllers.
• Use thread‑safe context objects (Current) for tenant information.
• Design the UI for fast workspace switching.
• Keep background jobs idempotent and tenant‑aware.
• Cache per tenant when appropriate to reduce database load.
• Monitor performance per workspace to detect heavy tenants early.

Conclusion

Building a multi‑brand SaaS in Rails isn’t just a technical challenge; it’s a design mindset. RobinReach demonstrates that with careful scoping, background‑job design, and workspace isolation, you can deliver a seamless multi‑tenant experience.

For Rails developers building SaaS platforms, these patterns can save you from future headaches and set your app up for scale.