Crisps abt Scalability Part 2

If you are reading this part for the first time. First go on with the previous post Crisps abt Scalability Part 1 of mine.

So what are the two alien terms I mentioned earlier. 

WT* is Master and Slave Architecture??

Simple as it name depicts. There ll be one master and the slaves ll listen to him. Soooorrry :P. Let me be clear. One of the implementations of master slave architecture is all writes will go only to the master and reads can be done from any of the master or slave. Ex: Redis Cache. And another way of implementation [I Hope] is master will act as a place holder of metadata about the location of data in its slaves. Ex: HBase (But this is totally different from the former, will be explained soon).

What is the advantage of this??? 

Consistency -> [Conditions apply]

How??

Simple, consider the same scenario of shopping cart. The problem was not about reading the data but writing.. right?? So, we converge all the writes to one common location so that the conflicts in consistency will be resolved at one point. Now the application looks almost like a usual single server model if u consider writes. Problem solved?? Yesssss :) But the answer is no :P 

WhyyyyyyT*?

Now comes the concept of Single point failure :) 

WT* is that?

Ha ha he he, Im there. Means your application has only one entry point for writes. So what if the entry point fails :( Everything is gone :( So, there are many other mechanisms which handles such fail overs. Like hardware, software and information redundancy blah blah n all :) 

OOPs So now all done??

You want me to say yes?? The answer again is no :P There is one more simple thing. 

What is that?? Is that really simple??

Ha ha :) You have got me right :P It is seemingly simple. The problem of write consistency is over. But read consistency??? The thing is How ll master update its slave. And when should it?? There are two ways push based and pull based. Push based is like when ever there is an update master sends an update to all its slaves to maintain consistency. Else the slave can ask for an update from master for a piece of data. Next when?? Periodically or Trigger based, based on the level of consistency application needs.

Atleast Now is it done??

Sorry to say this again the answer is no. Because there is one more issue with the previous issue :P It is, Will the master r slave will be able to respond to requests if they are getting or sending updates?? It is once againg based on the factor availability. In redis the Master side is non blocking but the slave part it is a blocking process. God should help :P So, there is a special care that needs to be taken if there is a update cycle running.

So, I'm done for Master Slave Architecture

Lets list the overheads and [de-merits may be] now

1.SPF

2.Master might get overloaded on write heavy apps

3.Update cycle

4.Availability

Did You see any of these overheads in ur single server implementation?????

1, 2 and 4 are still a problem of in that model too. 3 alone is an overhead. But that makes the big difference. If 3 is not handled properly read consistency will not be achieved. Then all is gone.

I hope now you understand why scalability might even degrade your performance instead enhancing, if you choose a perfectly wrong architecture. I have highlighted it because they ll not always degrade provided if u understand what you are implementing is appropriate for your application. Because Google and facebook are able to serve requests in n*billions using appropriate distributed architecture for them. 

In part3 I'll deal with the other one sharding or shared nothing architecture too. And let us see how it helps :)