I'm developing a SAAS Application using a hybrid sharded DB model with EF Core / SQL Server (to be hosted on Azure).
Is it best practice for every entity owned by the tenant to have a shard key (TenantId) or just the root entities.
For instance, a Customer can have multiple Addresses. Is it best practice for both the Customer and the Address have a TenantId or should just the Customer have a TenantId as the Address belongs to the Customer anyway?
My assumption was that every entity should have a shard key to facilitate tenant data migration (split/merge) from one shard to another but I've come across conflicting opinions on this.
NOTE: all entities have Guid Ids.
Any assistance would be appreciated.
Mat
Related
I started reading microservices architecture and got confused with one below point.
Each service should have a separate database.
Does each service mean a single web(rest) api having its own database?
For example if I take motor insurance claim operation as a business scenario where I modelled business domain services in 3 part Insurance claim services , partner (automobile service providers) services and customer services.
Insurance claim settlement operation in claim api will require other information like incident , survey done by an inspector, policy detail , documents etc.
Now I can create 5 web(rest) api in Insurance claim services and will store its data in common db and other services like partner and customer service will have their own web apis and db
What is correct ?
All web api (claimAPI, PolicyAPI, IncidentAPI, SurveyAPI and DocumentAPI) in claim insurance services should have their own db or they can keep data in single data base ?
Thanks.
To follow microservice best practice, it is correct that they should each have their own database and be exposed solely by APIs. This is because every service in your architecture should be independent and de-coupled from other services. If 2+ services share a database, then there may arise problems in operation or upgrade.
One big issue with a shared database is each service would need to trust that another service doesn't modify it's information. But since they all have access to the same database, one of the others could in fact modify the underlying data and make things unstable or insecure.
Further, with 2+ services relying on a shared database, then you're forced to use the exact same database/version with all. You lose the freedom to independently use MySQL for one and MongoDB for another. Even if the same tool is used for all, when you do maintenance or migration on one you're forced to do it for the rest. All this adds up to some coupled services that make them harder to maintain and scale.
you can have common database for all microservices, it is one of the microservices patterns:
https://microservices.io/patterns/data/shared-database.html
https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-data-persistence/shared-database.html
check those links to see advantages and disadvantages of this approach.
Let's assume below scenario.
There can be multiple tenants. Each tenant offers different services based on their business to clients. Depending on the size of the client, they may have their own database as well (ex:- Large clients prefer their data to be isolated).
Arranging tenants to fulfill above scenario is possible with the AspNetBoilerplate out of the box.
Then comes the customers who consumes various services provided by multiple businesses (tenants). There is a single mobile app for these customers. Once they login, they should be able to get services from any tenant unless a tenant has blocked a user.
Note that the point here is these customers are NOT registering for each tenant separately.
What are my options to get this setup done properly using AspNetBoilerplate? My initial thoughts are;
1) Have a separate table - MyCustomers - All mobile users will get authenticated against this table. For this should i create a separate auth pipeline ?
2) Current AspNetBoilerplate demo; you choose the tenant and login. But in my case; they log in and they will choose a service provider (tenant). At this point;
Should I create a new user automatically IF the selected tenant is in a different database (For large businesses having their own database)?
If the selected service provider is a small customer, who are in the same database differentiated with a TenantId I will have to additionally have a --> (many) relationship maintained so when a new service is selected a new record goes to this table?
At the end of the day, MyCustomers will only be using a single mobile app to get any service from any business after they login. Once they login, they should have access to all tenants (unless they are blocked).
Is there a better way to do this using AspNetBoilerplate existing architecture?
I've just started separating my projects out into little microservices. I have a microservice which deals with API authorization (checks if an apiKey provided in an API request is valid) and so for this, I have a separate DB for the API Authorization which has the following tables with the following schema:
APIKey:
ApiKey (VARCHAR, PK)
TenantID (INT, FK)
Tenant:
TenantID (INT, PK)
Name (VARCHAR)
As you can see the APIKey table is linked to the Tenant table.
I have another microservice, this microservice deals with storing errors for tenants and so requires reference to the tenant table, but because the Tenant table is in a separate DB, we can't actually use it.
I thought about creating a Tenant service and having a DB just for Tenants but this would cause data integrity issues on other microservices which require some reference to a Tenant so I'm not sure what I should do.
Can anyone suggest what should be done?
The microservice for tenant errors seems to be a nano service. It sounds like you're actually using it for monitoring. There are more monitoring solutions out there such as Splunk and ELK that can do more generic logging. If you have other microservices, they can also log the errors to them.
If you used a monitoring solution, you wouldn't need a tenant error microservice and you also wouldn't need a tenant microservice as you suggested. If you wanted to continue down the path of having individual services though, you could publish the error events and tenant events to a queue from the API authorization service to the tenant microservice or tenant error service. So you will have replicated data and will need to strategize keeping the data consistent.
Arguably, this leads more complexity due to how you decided to split it into those respective microservices. On the other hand, a shared architecture would solve your problem but at the same time, couples your architecture. The reason microservices exist is to essentially to move away from coupling so I would recommend going back to evaluate whether that decision on defining those bounds for the services and see what you can join together to either eliminate or minimize the complexity.
I am working on a multi-tenant app in MEAN stack, in which user will signup and using their business names I will create an account(sub-domain) for them : abc.example.com.
So what approach should I use for this multi-tenant app?
A single database in which each client have their specific collection.
Or, should I maintain separate db for each user signup ?
In my application, I will be having 3-4 fixed collections for each user.
So out of these two which will be more beneficial and If you can also provide any example to support your answer ?
There are a lot of criteria that you need to look into before switching to the separate database per tenant model
Tenant volume, the number of tenants in the system
Volume of data per tenant
Compliance requirements like HIPAA that you have to adhere to the tenant
Geographical diversity, one tenant in USA and other tenant in Asia etc...
Both the options are fine, but once you are not able to predict beforehand the values for the points 1 through 3, you can just use the same database with a tenantid column and later scale out to per tenant database with ease.
If you have some values for the above mentioned points, the community here will be able to guide you better.
I have a completed asp.net mvc 3 web application which relies on a mysql database and a mssql authentication/authorization database. How should I go about converting the application into Software as a Service - specifically with relation to having multiple tenants? Should the database just have its tables segregated based on tenant ids, or should there be one database per tenant? Are there any books or good sources I can reference? I am just trying to see if there is a best practice for this, or if what I am doing is standard.
Software as a Service is a huge industry and is rapidly growing. Major educational players are actively investing in including coursework regarding SaaS. One such institution is Unversity of Berkeley, California. They offer a free online course on SaaS at edx.org. The two professors teaching the class are highly acclaimed. The book for the course can be purchased via their site or through amazon.com.
Note: I am in no way affiliated with the course, the University, the professors, any of the free online education sites, nor am I enrolled in the class. There is not much content available on SaaS and this is one of the only sources that I was able to find.
Edit
With regards to the database, to convert from a single tenant to a multi tenant system, an abstraction must be used in order to separate the content. However, this will undeniably multiply the amount of content by the amount of tenants in the tables resulting in slower query times. In this respect, the tables must be partitioned by tenant ranges, with views representing those partitions. These views can then be queried.