Tuesday, October 21, 2014

Scalable Architecture for Rest API

https://blog.apigee.com/detail/scaling_apis_predict_prepare_for_overcome_challenges

https://blog.apigee.com/detail/huge_running_an_api_at_scale

https://blog.apigee.com/detail/cache_large_chunks_in_the_api_response

https://blog.apigee.com/detail/in_the_cloud_scale_means_concurrency

https://blog.apigee.com/detail/cloud_security_tech_talk_series_security_and_scalability

http://www.restapitutorial.com/lessons/whatisrest.html

http://www.ibm.com/developerworks/library/wa-aj-multitier/

designing a high-scalability, high-availability site

 

We find that Restlet does scale very well with the right system architecture.
Generally speaking you want to:
  • Run a cluster of web server machines, not just one.
  • Make sure your application is shared nothing, ie, no application state stored in your web servers, if at all possible.
  • Use a load balancer to spread requests to the least loaded web servers.
  • Make sure your JSON responses are cacheable.
  • Add an HTTP reverse proxy cache (eg, Squid) at the border of your site. As the caches between your site and your clients warm up, most of the inbound traffic will be handled by them, and not your web servers.
  • Write your client code to retry requests that fail. This way if a web server dies the next request will be load balanced to a surviving machine.
  • And of course you want to automate your site to bring up crashed web servers, etc. (This is the part that is perhaps better asked on ServerFault.com.)
REST is an architectural style that is ideal for this type of setup.
As @matt mentions you do need to watch out for raw performance, but generally your first concern should be to get the scalable, high availability architecture in place.
Some good sources on this are:
and especially:

No comments:

Post a Comment