Have come up with architecture for things I had in mind and readings I have been doing a lot. Shown below is a scalable architecture, according to which the software architecture should be written for an application which will be used in different locations and requires geographical based traffic optimizations.

I will be requiring lot of inputs from readers to correct this architecture discussing various problems with it along with enhancements that can be done. Will really appreciate inputs. I can also be contacted at parag dot arora at gmail to discuss a better architecture for the given need.

hardware-architecture

• Web Servers: This will be first level of geographical mapping of servers. Web Servers will be also having a view caching so that the view loading is enhanced in terms of speed. The scaling of web servers will depend on where (in terms of geography) the traffic has been increasing. A person sitting in US will be actually accessing a server based in US and person sitting in India will be accessing a server based in India. Such mechanism will ensure fast connectivity as accessibility time will be reduced. There will be a master server where the IP’s will be mapped to server address in a hash table which will be cached in RAM and after detecting client’s IP, we will direct the client to the server in their area. To start with, this master server will act as the web server and the scalable web servers mentioned will be introduced as we start entering into other countries. The best mechanism will be to have dedicated domains like .co.uk, .co.in, .co.us etc. for web server mapping.
  
• App Servers: Web server will interact with application servers where the business process will be done. The application servers will host business process of features and will form a bridge between web servers and database. Each web server will be mapped to one or more application servers which will reside in the same geographical location as of web server. Initially, in the first phase, application server and web server will be physically same machines. Most of the AJAX functionalities will be served via these servers only. All the dynamic information will be served via these server and web servers will host only template files and javascripts or more precisely the client side interaction code. Sessions will also be saved in app servers.
  
• DB master servers: Application servers will directly interact with database master servers. Sharding will be done in database which will be done through master-slave architecture using entity lookup services. The core purpose of master servers will be to maintain slave mappings w.r.t. entities. e.g., if there are lots of micro updates entered by users, then we will use sharding techniques to save these updates. Every user will be mapped to a slave database servers containing micro updates table and master server will maintain a memcache which will contain a table mapping users (or a user groups to enhance efficiency and decrease data stored in master servers) to slave servers.
  A problem exists for such an architecture. Suppose the user lives in India and web server in India connect to App Server which try to lookup user in master server memcache. If users try to connect from India, then there will be no problem. Now suppose that the same user goes to Canada and try connecting to our website. Then obviously memcache placed in Canada will not contain this user record.
  The proposed solution for this problem is, we will maintain the universal copies within the database and memcache will only contain the active users’ data. If the user (discussed) record is not found in memcache of master db server in Canada, it will query the user record from the copied database and save it in memcache.
  The slave access will obviously be little slow in this case since the data finally is retrieved from server based in India but this is obvious as we should not maintain lot of copies of same data. This server will require lot of data copying and will be little inefficient in terms of storage but will be useful if the users belonging to website shifts their locations too often (more travelling users).
  The other solution to this problem can be master web server will contain the access server of every user and in addition of keeping track of ip of user from next login, it will also contain user – access server mapping in the lookup table. This approach assumes that most of the users will not shift countries too often.
  
• DB slave servers: Wherever sharding is used, master servers will save, update or retrieve data from these slave servers.