hellsten + distributed   15

Consistent Hash Rings Explained Simply
- you may want to take a URL and get back the server the website is hosted on.

- The problem of mimicking a hash table when the number of locations are constantly changing was exactly why consistent hashing was invented.

- For 2,000 keys spread across 100 locations, you now need to move only 20 keys to a new location if 1 location with only 20 keys goes down.

- This is the main benefit of consistent hashing: you now no longer need to move so many things just because one location has disappea...
algorithms  algorithm  distributed  consistent-hash  hash  cs 
january 2019 by hellsten
Vector Clocks Explained
Vector Clocks by Example

We’ve all had this problem:

Alice, Ben, Cathy, and Dave are planning to meet next week for
dinner. The planning starts with Alice suggesting they meet on
Wednesday. Later, Dave discuss alternatives with Cathy, and they
decide on Thursday instead. Dave also exchanges email with Ben, and
they decide on Tuesday. When Alice pings everyone again to find out
whether they still agree with her Wednesday suggestion, she gets
mixed message...
algorithms  distributed  distributed-systems  clock  vector  time 
january 2019 by hellsten
Raft Consensus Algorithm
Raft is a consensus algorithm that is designed to be easy to understand. It's equivalent to Paxos in fault-tolerance and performance. The difference is that it's decomposed into relatively independent subproblems, and it cleanly addresses all major pieces needed for practical systems. We hope Raft will make consensus available to a wider audience, and that this wider audience will be able to develop a variety of higher quality consensus-based systems than are available today.
raft  consensus  algorithm  scaling  distributed 
june 2016 by hellsten
Related Projects · mperham/sidekiq Wiki
@mperham's note: job uniqueness or locking is impossible to implement safely and efficiently in a distributed system. I recommend using optimistic or pessimistic locking with database transactions instead of using these projects.
sidekiq  locking  distributed 
may 2015 by hellsten
ggtsu_00 kommentarer på What microservices look like in production
Distributed transaction systems are not that complicated. For a user registration example, say you have 2 services on separate locations and can only communicate over http. One manage the registration process, the other manages user accounts. The user hits the registration page which issues a request to the user account service to create a new unregistered account and returns with a transaction id. The registration services creates a row in its own database using that transaction id as a key and fills in the requirements before posting it back to the account service to complete the registration process. If a failure occurs during the registration process on the registration service, no account is ever created in the account service so no roll back is needed. If a failure occurs on the account service side, that wouldn't be a problem since the registration state is still intact and the transaction can be reissued by the registration service if it doesn't get a 200 response code back from the account service. If the response times out but is actually completed, upon reissuing the request, it should return back with an error code saying the transaction is already completed so the registration service can know it was done successfully.
Basically the transaction won't be complete until both services shake hands and agree that it is complete and either party won't commit anything to their databases until then. No need for locks, just use UUIDs for your transaction IDs and you are set.
microservices  architecture  soa  transaction  distributed 
november 2014 by hellsten
Coding Horror: On Working Remotely
I believe remote development represents the future of work. If we have to spend a little time figuring out how this stuff works, and maybe even make some mistakes along the way, it's worth it. As far as I'm concerned, the future is now. Why wait?

Future of work. Yeah, right. Right as our very industry has gotten on the scrumtrain - you know, the one that says that people must work face-to-face, in open office environments, and have a meeting every single morning at the right time, and should use sticky notes instead of electronic tools.
scrum  remote  distributed  agile  productivity  programming  collaboration 
may 2010 by hellsten

Copy this bookmark: