We have a SAAS system deployed in Azure (as a Cloud Service), which contains multiple ServiceStack micro-services, which would be load-balanced to serve multiple clients to multiple tenants.
Each client will be hitting a sub-domain of the main domain where the service is deployed.
For example:
-
jimmy will be hitting
https://jim.acme.com/api/banana -
mary will be hitting
https://mary.acme.com/api/banana -
jill will be hitting
https://jill.acme.com/api/banana
All these requests will be going to the same logical service, deployed once in each cloud region.
That service needs to figure out which tenant the request is coming in for, and load its connection strings appropriately for each request.
I see that ServiceStack meets the need to switch the DB connection string at runtime, documented here, which is fantastic, but that is only half the story really.
My question is to do with the mechanics of this in the context of building a scalable cloud system (in Azure).
I would prefer to have a piece of infrastructure handle the following things, rather than coding it all into my service. But keen to see how others have solved this kind of problem.
I am looking for a design pattern or collaboration with a piece of infrastructure that would do something like:
- Handle the HTTPS request, figure out which subdomain it is for, and forward the request to the back-end service, for example, with a request header that states the tenant. eg:
X-Tenant-Id: jim. End to end as HTTPS. - That means it would probably need to define multiple IP addresses, one for each subdomain, with an SSL cert.
- Would be nice to act as the load balancer as well, but that can be between it and the backend service too.
What sort of design have people used for this kind of thing?