switchman

Define "as they're supposed to be". Back when I worked for Instructure ~10 years ago, Canvas was effectively a single, giant, monolithic multitenant app with one instance backed by several thousand app servers and ~100 separate Postgres database clusters that any app server could talk to. Schools were grouped onto pools of app severs and Postgres database clusters more or less according to locality and cluster availability. I want to say a handful of the largest schools got their own clusters, but I'm not certain, and at any rate their clusters could certainly all talk to each other. It was actually kind of neat from a technical perspective: any Rails model across the entire Canvas world could have a "foreign key" pointing to any other Rails model anywhere else. Among other things, this allowed for users who could administer multiple Canv

One of the largest open-source Rails apps has all of those features: Canvas LMS[1]. It uses Switchman[2] for abstracting the multi-tenancy logic. Their approach has scaled to millions of concurrent users, but admittedly not helpful if you’re looking for a guide since the code is buried in a legacy monolith. Part of the reason there isn’t a generic guide to this is that multi-tenancy is probably a premature optimization if a generic guide would be helpful. Just use nested user accounts to accomplish your business logic. By the time you really need true multi-tenancy, generic sample code won’t be much more helpful than the docs of the various plugins like Switchman. 1: https://github.com/instructure/canvas-lms 2: https://github.com/instructure/switchman