Laravel architecture for Saas systems

Question

I am making a system in Laravel, but this system will serve several users, and these users can register their customers.

The big question is, so that it doesn’t stay all in a single database, I thought every time the user registers in the application, create a new database, and within that database run the tables Migrations.

However each user, will be able to register their customers and these customers will have user and password, in the login I would have to pass bank to bank to know which bank that customer is to do the authentication... so I no longer found a legal practice, another option is to ask for an identifier when logging in, but I don’t think it would be good practice as well.

The last option is to create a single database with all the data, only the tables would become giant...

Some architect could give me a light?

Answer 1

This system of yours seems to be a Saas (Software as a Service), which is a form of software distribution where systems are accessible from multiple devices through a client interface on a client-server model network like a web browser. In Saas, the user does not manage the application’s individual features, except settings specific to its environment.

These projects are identified as multi tenant systems (from multiple tenants). There are several approaches that deal with the database model and even the existence of subdomains per client (user) of the application.

Speaking specifically of database and considering a single system code base (installation), briefly:

1. In the approach where all users are in a single database, it is necessary that each data table has the relationship with the correct primary key of the user Owner (owner)and care that all manipulation and access to the data is carried out only to the records that the Owner has. Advantage is in architecture and maintenance, as only a database update is required in changes. As for data volume, if well modeled and implemented, the database will have the required performance.

2. In the approach of a database per tenant (tenant), the system can access all the data without concern in validating the accesses to the records of Owner users only. Disadvantages, the infrastructure is more complex, with each database update it is necessary a tenant X bd effort, besides a centralized database for the management of the users and the access to the correct bds. Or use the company "choice" strategy on a login screen. Or if you use subdomains, controlling in the central comic only the access to the correct bank. Or standardize the name and access to the comics according to the name of the subdomain.

If you think of a multi-facility platform, one per user, it would have the complexity of item 2 above, plus keeping the synchronized update of each source code installation under maintenance.

When it comes to Laravel, I have a greater experience with Saas from a single bank and it works well. My system uses the package https://github.com/nunomazer/laravel-samehouse. But there are other excellent packages that support both strategy, are they:

• Laravel Same House - https://github.com/nunomazer/laravel-samehouse
• Laravel Tenancy (formerly Hyn Tenancy) - https://tenancy.dev/
• Spatie Laravel Multitenancy - https://github.com/spatie/laravel-multitenancy
• Tenancy for Laravel - https://tenancyforlaravel.com/

Answer 2

I have a similar scenario, but in my case, I have a "club" database, where you have your login data and the database access data of each, soon when you login, I perform the search inside the club database, and then when you find, collected the data for access to own database, where it contains the data of specific users of that club.