[erlang-questions] Twoorl: an open source Twitter clone

[Joe Armstrong]

On Wed, Jun 4, 2008 at 12:16 AM, Paul Fisher <pfisher@REDACTED> wrote:
> On Wed, 2008-06-04 at 00:06 +0200, Dominic Williams wrote:
>> Hi Joe,
>>
>> > It would be a zillion times easier if the *client* did
>> > all this messing around. If the client knew about N
>> > server address it could automatically redirect to a
>> > different server if the primary server failed. if the
>> > client knew about N machines and performed the md5(Key)
>> > calculation to find the correct machine then the problem
>> > would be very easy to solve with no messing around in the
>> > server.
>>
>> Indeed, and I've used this strategy in the past on systems
>> in which we were responsible for both client and server.
>>
>> It has one problem, though, which is if the network is not
>> completely reliable and can become partitioned - different
>> clients can end up using different servers, resulting in an
>> inconsistent state. The way around this - leader election -
>> works nicely in small systems but surely it doesn't scale to
>> millions of clients?

Right - but now we need to analyse the consequences of
of a partitioning. I can imagine two extreme end-cases cases

1) best effort repair - basically ignore consistency - two different
users could get different
subsets of the information - this will only happen when the system is
failing and
will only effect users on the failing machines.

2) strong consistency (all uses get the same consistent view)
Expensive and difficult


(then there are many inbetween cases)

For a free service then 1) would be easy to implement and "good enough"

For a fully paid service then 2)

1) should be easy to do without a fully synchronised back-end - use a
simple gossip and the
notes will "eventually" become consistent.

As long as the users are aware of this it shouldn't be a problem.

/Joe




>
> This is why systems that use hashing to distribute load like Amazon's
> dynamo also employ a "gossip protocol" to maintain group consistency and
> perform failure detection.  Even though it is not stated more
> specifically in the paper, it is a reasonable guess, base on the
> background of their CTO (Werner Vogels), that this employs some form of
> virtual synchrony.
>
> The node receiving the call from a client (which may be behind in group
> membership and partition knowledge) will set it straight.
>
>
> --
> paul
>
>