Distributedness considerations
What we try to minimize is the time spent from the moment the user clicked on a link or a bubble until the effect has happened (the page loaded or the bubble expanded).
The possible reasons behind slow operation:
- poor (or enterpriseyly complex) coding
- slow machine on either the client or the server side
- big latency tcp connection from the client to the server
- extreme load of the server
We can (and should) address the first one, we are gonna have somebody working on a "profiling sprint". The 2. is not in our hands (we buy/rent a machine on server side what we can afford, and can't control what the user uses on the client side.)
The 3. issue is somewhat tricky. Let's say we'd like to break in to the Uzbek market. It is absolutely impossible by having only a server in Hungary, as anybody operating a server right in Uzbekistan has a huge advantage because of faster access. So we need to have several servers, operating in master mode, to address this issue. This is what Misi is working on. This needs a great deal of planning (for example: let's say we have a US and a HUN server. Which one is thiblo.com? As we plan to use subdomains for the blogs, just as blogspot.com, it is not ideal to include the machine identification in the url, e.g. football.us.thiblo.com or us.football.thiblo.com or hun.baldvin.thiblo.com.
A possible solution is that we make our DNS reply either one of the IP addresses according to the physical location of the source of the query. It needs some further investigations.
As of extreme loads of the server: I don't expect at all that we are gonna be that wildly successful in the first months that we would need to bother with this question. Maybe we give it a thought before installing the production version, but we don't need to spend many time on it now, because:
When?
We know services which are wildly successful but are a failure on the other hand: they didn't write a code which could be made distributed, so after they conquered all of Hungary, the only solution to the slowness was to put bigger and bigger hardware under them.
So what I would like to assure that we never restrict ourselves to using some technology that can't be made distributed without rewriting the whole thing.
Issue 3 (latency) was to be addressed now, since going multi-master might affect the design of the middleware too. We don't know yet if it does or doesn't, but might.
Issue 4 (big load) on the other hand is something that is much better treated in the literature: when time comes, we can separate database and middleware servers at all master points, we can use load-balancing or whatever locally.
I believe that being successful depends on how fast the page loads for the first users, so dealing with issue3 and profiling the code is very important.
