I am developing a textile shop application in .NET Core using the Entity framework. So I am developing it in Azure and using the same application for different shops using Shop ID as the primary key.

In theory that's all working fine for different kinds of shops especially since the concept is the same among any size of shops.

But the problem is, in a huge shop the transactions will be very high (Traffic). So they cant accept a delay in service provisioning. So when multiple huge shops using the same DB, that could end up drastic delay in delivery for smaller shops as well.

As a solution, I thought about using an On-Premise DB for big shops and sync it with the Azure SQL. But a question arises, how fast it should sync. Because there are public users are using an app for these shops to buy online. So if a delay in sync could end up in wrong stock info for online customers.

So which is the best and effective way to handle the scenario. I am happy without an OnPrem solution, but a great configuration in Azure DB itself.

Please suggest! Thanks in advance.

2 Answers 2


One option could be to have a bunch of databases in an azure sql elastic pool. It depend on the number of shops but ideally you cold have a db per shop.

If the trafic is high, try to reduce the in/out data amount between the database and the applications; options are caching or query optimization and good indexes strategy.


I like the reply that @MBuschi but I would like to add something.

I have worked in a company that was providing the same service and I think the solution could be applied in your same scenario and my suggestion is: go Single-Tenant (option 2 in the image).

enter image description here

  1. Order: is good because it will allows you to separate the data, so when a customer goes away you can just drop the database. Leave Multi-Tenant (option 3 in the image) for Uber and Stotify, they are Business to Customer, you are more Business to Business, right?
  2. Costs: You can stipulate a contract with the user for which they pay for their consumption. So they will be charged monthly their consumption + the cost of your application.
  3. Performances: As @MBuschi said you can also put the databases in an elastic pool and minimize the costs and have better performances.

...but I would not suggest you to go hybrid. If you go to the cloud just stick with it and put everything on the cloud. The scenario you want to avoid is to have customers on the cloud and on-prem: that will be the nightmare because, want it or not, you will end up developing two different applications.

"...no, but really, the application is the same on-prem and on the cloud..."

Yeah, maybe now, think about the future...

  • Thanks for sharing your suggestion.. In my case, we are actually using same application for multiple shops.. so all are differentiating using shop_id primary key May 31, 2021 at 8:42
  • 1
    @SandeepThomas, you are right, I update the image. The second scenario is your and it's still called single-tenant. the option 3 is multi-tenant May 31, 2021 at 9:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.