Ask HN: How to scale or rearchitect a single portal site to a multi-tenant SaaS

Haha, I'm working on a multi tenant guide for my employer (an identity provider), which will at least cover the login/logout/registration behavior.

> What is the correct term for this multi-tenant setup

Private label, white label.

> I can use the site I have as a template to spin off new sites in the new SaaS?

Do you want to update the application to handle multiple tenants? You could also spin up an entirely separate physical application (a new WAR file, if you were building it in java). But this is simpler to start, but will lead to complexity in the end, as you will have to deploy to N sep instances on update.

> What technologies am I looking at utilizing to build out such

Any tech can do it. Here's the example app I'm building in PHP: https://github.com/FusionAuth/fusionauth-example-symfony-mul...

Thank you for the response. When you say spinning up separate physical application, I am guessing this is for isolation concerns? What would be the best way to handle especially data isolation? Would each spinoff have its own database or it would just be an application but reading from one master for all the schools?

I am trying to think of this from the point of view of a front-end user who graduated from 2 different schools and needs to get notifications/updates from both schools in a single front page. Which isolation approach has a better security vs efficiency balance?

So you have two different main levels of isolation. The first is physical:

For each client, you have:

   * sep web server
   * sep database
   * same codebase

The wins with this approach:

   * can live in different geographies (for compliance or data sovereignty)
   * downtime for one webserver/app doesn't affect other clients
   * no intermixing of user data
   * clients can live on different versions quite happily

Downsides:

   * deployment becomes difficult
   * more expensive because you scale servers linearly with clients

The other option, far more common, is logical isolation.

   * same web server (filter traffic on hostname or some other attribute)
   * same database (have a 'tenant' table and a 'tenant_id' FK in every relevant table) 
   * same codebase

Wins:

   * operations are much simpler--it's one application that looks to users like many applications
   * will be cheaper. Even if you need a bigger server, the price won't scale linearly with # clients

Downsides:

   * can't, except through feature flags or other custom coding, have users on different versions (see what Stripe does: https://stripe.com/blog/api-versioning )
   * one client's traffic can affect other clients (the noisy neighbor problem)

> I am trying to think of this from the point of view of a front-end user who graduated from 2 different schools and needs to get notifications/updates from both schools in a single front page.

That points toward logical isolation, because at that point you can have 'global' logic that spans tenants. That is possible to do with physical isolation (network calls), but much more difficult than with logical isolation (a database call).

> Which isolation approach has a better security vs efficiency balance?

That's a tradeoff only you can decide. It's more typical to use logical isolation, however.

If anyone is interested, here's the guide I mentioned: https://fusionauth.io/docs/v1/tech/guides/multi-tenant/

Like several commenters pointed out, using separate systems seems the best approach for the short term.

I suggest that you first implement the system for multiple schools before re-architecting your system. Your will have better understanding about which parts of the system should be customizable and which ones should not.

Do not attempt to make your system overly customizable. I have seen several systems where almost everything could be customized. In most cases these were pretty complicated to use, and of when the customer came with some request we had to change the customization code itself, because the request could not be satisfied with a change in customization parameters.

One solution would be to dockerize your current setup and then spin a container for each school.

Then with nginx, point example.com/school1 to its corresponding container.

Thank you. What about data isolation? Would each containerized app have its own database or would all of them be reading from the same master?

If you are in the EU I would definitely advise to use separate databases due to privacy laws (GDPR). This also keeps your database and queries simpler because you don't need to use a separate a separate tenant ID column.

That would be your decision to make. It is actually easier to have a separate db for each.

This is reasonable in the short term.

Pros: You can probably make it work in a day or two

Cons: You now have to manage resources for each school. With dozens it's no big deal, but with tens of thousands you've got a considerable deployment problem.

I have worked at a company that started with a few single-tenant instances and ended up with a thousand. We ended up building software to specifically manage deployments, do healthchecks, ensure isolation etc (it was a long time ago - I expect we'd just run a giant kube farm today).

So, this is a reasonable approach with a painful trade-off as you scale. I would do this in the short term whilst working on refactoring this into a multi-tenant app.

You'd create a table that holds the different tenants. Then add a association between users and tenants. Store the tenant in the authenticated users session.

Then you could attach the tenant specific configuration to the session too, or better keep it in an in-memory cache.

Depends on the tech stack you want to work with. What you are describing is often called "white label".

The simple way to build this would be to store each customer's data in a database.