Which way to go in multitenant?

[mkevison]

I am creating a sports betting system and it must be multi tenant.
It is a very complete system that demands a lot from the database, in addition to receiving several requests, it also executes many requests with the odds api. In these requests the json files exchanged reach 3mb in size.

Is it worth creating this multitenant system or is one server better for each client?

And if it's better to go by the multitenant which way to go?

How do I make a database for each client and make the request using the model for a specific database?

[davidharting]

I personally would instead reach for a solution that you did not include in your original post.

I would do one database, and use account_id on database records to identify which records belong to which tenant.

This pushes tenancy up to be an application level concern. This means you have to add extra where clauses to all your queries.

However, it has a lot of benefits.

• simplicity. You don't have to worry about managing many databases.
• flexibility to evolve your data model. For instance, one user can belong to multiple accounts and see all their data in one page (and you only have to query one database).

My understanding is that this is the most common pattern for multi-tenancy in SaaS applications.

[mkevison]

I'll go that way, thanks!

[davidharting]

Sure thing, multi-tenant is always a fun discussion!
Hope your project goes smoothly.

You mentioned that there is a large payload size with the odds API, >= 3mb in size.
I do think large payloads can be a cause for concern, regardless of the strategy for handling tenants.

Are any of these possible:

• Caching the response (like in Redis or Memcache)
• Adding paging to the request and not fetching all of it at once
• Pushing work back to the server so that the client never needs this payload
• Doing work in background jobs (for instance, with BullMQ) and simplifying the payload / server-work that is requested in the controller

Without knowing more about the odds API (what it does and how it is used), it's hard to know which of these (if any apply).