I have to make an architectural decision for an application and would like to know the best way to achieve the following, hopefully without having to keep information duplicated or in multiple places.
Scenario:
- Application instances with separated, autonomous parts of the entire user data are split across multiple, geographically dispersed servers (e.g. users 1 – 1,000 on server 1 in Honolulu, users 1,001 – 2,000 on another one in Tokyo etc.).
- Single user data is available only once on one server in the entire system and not available to other servers.
- Users don’t care about other user’s data so there no intrinsic need for communication between servers.
- However, the application needs a central point of login, lets call it http://www.mysite.com/login
My initial idea was to have a “master” database that keeps all users and their server location and then redirects to the appropriate one upon login.
Is there an easier/better way to do this?
Depending on how many servers you have, an alternative is to have the “central point of login” send out (“broadcast”) each login request to all servers; most servers will rapidly answer “user unknown”, one will identify itself as the one the user resides on, etc etc. Whether that’s preferable to managing “replication” of info to the “master database”, ensuring consistency, etc, etc, is hard to say given the sparse information, but at least it may be an alternative architecture worth considering.