Technology stack for Highly Scalable REST Web Service implementation

up vote0down votefavorite 1

We need to come up with a REST based web service implementation returning JSON from a Data Store that needs to be highly scalable. The primary design requirement is high scalability because this service is going to be hit by hundreds of thousands of client apps(C++) at a predefined polling interval. We are asked to propose the technology stack for the Web Service and the Database. Initially we thought about ASP.NET MVC 3 for the REST API and SQL Server 2008 for the database. But the client is asking us whether this is scalable enough. Since we are a Microsoft group, we are more inclined towards MS technologies but we want to be unbiased and propose a couple of best fits in this scenario. If some other technology stack is better suited to handle the load and scale, then we would like to present that to the client rather than trying to bag the project for ourselves. We are just not sure how to go about coming up with a comparison since there are so many frameworks and available technologies to implement REST. We were also trying to figure out if a NoSQL based solution would help the scalability as there is no real reason to use a relational data model as the database will just be used as a data store. Does any body have any suggestions around the choice of technologies that is best suited to handle the above requirement. rest scalability share|improve this question asked Sep 18 '12 at 6:32 koder 1936

add comment

1 Answer

activeoldestvotes

up vote1down vote

Any of the mature web technologies (.net, java, php, etc) can be used to create a scalable REST api. If you application is data intensive, then I would go on to say that more than the web technology, it is the data store that would matter more. To decide on the data-store, you should first check if the app is read intensive or write intensive. If its read intensive, a RDBMS with a caching solution (EhCache, Memcache, etc) should serve you well. If its write intensive, you may want some sort of write sharding - you may be better off using a NoSQL solution like Cassandra/ MongoDB, etc. Also consider licensing costs. With SQL Server most of the scalability features (partitioning, etc) are Enterprise features. With MSSQL 2012, license is per logical core and not per physical processor. If this is an issue, you may seriously want to consider MySQL instead of MSSQL. share|improve this answer edited May 10 at 20:28 answered Oct 21 '12 at 20:11 D K 64226

add comment