Want to maintain Single SQL Azure DB across multiple regions

Question

In my application I have scenario like below.

• User downloads our application exe and includes in their application hosted in azure
• We have one REST API in every region for receiving data from application so that data transfer will not cost to the user
• The exe sends the data which is sent to the REST API in the region of the application
• The REST API stores that data in SQL Azure DB, which is hosted in one region

This way the cost of datatransfer is paid by us. Now, to reduce the cost we want to remove the rest api and store the data in the DB hosted across all the regions. This way exe used by the user will store data directly in the DB in the same region as the application of the user. We use this data in a webapplication for monitoring. I have identify three tentatively possible solutions:

1. Is it possible to have SQL Azure DB federation across multiple regions?
2. I can use DataSync with multiple DB in multiple regions.
3. Or in brute force method, i can have independent DB hosted in all regions and combine the data when using in the webapplication

I know that last method will work, but i want to go with it in the last place.
Can anyone suggest about federation across multiple regions?
What are the costs for DataSync?
Is there a better solution for this?
Thanks.

Answer 1

Regarding SQL Azure Federations: All federations must be in the same SQL Azure server, meaning same datacenter as well. I'm not sure what's on tap for future updates to Federations, regarding multiple servers.

Regarding data cost: Ingress is free, so regardless which datacenter hosts the REST interface, there wouldn't be a bandwidth charge for incoming data from your client applications.

I know you're not asking for architectural advice on REST vs. direct DB access, but... I'd give a bit more consideration to keeping the REST API vs. going with direct database access. By using the REST API, you'll have a nice way of scaling, as well as monitoring user activity. Also, you'd be able to change your schema (or move to Federations) transparently by just modifying your REST implementation, vs. pushing this knowledge down to your client application.