Hi Nate, On Monday, November 07, 2011 08:31:15 PM you wrote: > I appreciate you sharing your design. But I can never understand why people > go to such great lengths to add transactions to an eventually-consistent > db.
I'd agree that in many cases user registration doesn't need to be 100% available. But I thought I'd give it a shot, just for the challenge. I only recently got into Riak and am now quite fascinated with issues of eventual- consistency. > You could possibly solve the same problem by using memcached or Redis. > Example: > > 1. Look up the user in Riak. If that lookup succeeds, abort. > 2. Store a copy of the new username via memcached add() with a generous > expiry interval. 3. If it exists already (atomic in memcached), you lost a > race with another user and error out. If not, also store the username in > Riak. 4. The memcached key will expire at some point after Riak becomes > consistent, keeping your memory use reasonable. > > Is user creation such a high percentage of your transaction volume that you > have to build something almost as complicated as a VCS on top of it in > order to scale? For robustness, isn't it simpler to just disable user > creation if your memcached single-point-of-failure is down and you weren't > able to failover to the spare? Yes, that could work. There may be some edge cases to work out there regarding memcached failover (lost keys, spare doesn't have same keys), but you make a good point that it can be simpler to not try to do everything within Riak. Justin _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
