Scalability CheatSheet - Paxos

Scalability CheatSheet— Part 3 — PAXOS

We like journaling, seriously, it helps us avoid data corruption you could update a data and fail really — i mean there could be an electricity shutdown whatever, this is why we like journaling it’s append only, so nothing can really be corrupted except for what you append, but if it’s corrupted you don’t consider it as appended.

Reading is now difficult you need to read all your journaling, so from time to time you create a snapshot of state, you see so now you have a snapshot and you augment it with your appended only jouranling.

Just Read — When you read you just read, you don’t lock, you don’t care about the world, it’s like you are high you just read and reading now does not disturb any writes just read without disturbing writes, its immutable, all is cool dude, we are reading.

Collision — What happens if two distributed machines try to write at the very same time same timestamp and different content on same key? OMG we just have a problem even in append only journaling, let’s scratch our heads and see what we can do, calling turing might be a good idea, but he didn’t answer any of my calls for the last couple of years, so we’ll have to figure something out.

Eventually Consistent — Less is the new more — A secretweapon we came upon which basically means, we can’t have the best of all world and we don’t need to. For our cases we are going to satisfy with less. As each participant has its own local strongly consistent store, they update each other about.. updates. With eventual consistency you build a map with all nodes and update others when something happens and can change route no one node has precedence over others who has same data. —

The non real last state — so let us stress it again it is impossible for anyone to know the current and we are talking here on the real state, impossible to do proper read-modify-write, that is, with the top most update to date correct information without collisions,and in addition its vulnerable to network failures — but we already agreed, less is more! And the more here is that it’s much more

Paxos strong consistency - The whole target of paxos is to reach a consensus among members.

The Part Time Parliament — Quorum — Paxos is doing it in manner of reaching an agreement between chosen members, for example you need at least half the nodes to agree on it. The Paxos uses the part time parliament example — in order to make a change you have to get the agreement of the majority of the paxons. Now you cannot have two set of paxons both larger than half the group having the same decision on change .

Paxos is also for reading — likewise when you need to read something you want to know that you get the latest and greatest revision, so you need to get majority of the paxons to agree on latest revision.

So in paxos read the client asks all nodes for a value, a valid answer is when majority of all nodes agrees on value, yes of all nodes at least in the naive algorithm. No canonical place to store answer. This is naive paxos there are better.

Paxos Write — (ask → promise → accept) — here the client contacts a random node, asks it to write value, the node take the value and appends sequence number and does prepare (value, seq), all receiving nodes make sure seqnum is highest to accept a proposal, if the client would send proposal immediately without first contacting a node then if two clients do that each could end up with half the system agreeing.

Paxos has a way to generate only growing numbers with time, then if its the highest nodes agree to accept — promise to accept. Now counting how many promises we have, if we have promises from more than half majority before timeout then asking all promises to accept. if only some nodes managed to accept value, which means that reads would not get majority and would fail it sucks but at least we are not at inconsistent state.

Paxos cost — The cost a write is requiring consensus among majority of members you can no longer just write to your local journal.

Master election — Master election is just yet another example of agreeing on something, in this case you agree on master, it’s an expensive, strongly consistent store used to decide who is in charge then if you need something you contact him, but once you all agree on a master it simplifies your processes when you need to read or write you just contact me, so it eliminates further agreements on every read and write.

For each topic we have a status column, use it for our own to track the status of your progress in the study this topic. In addition, we have a tutorial column where we point to the best video or tutorial for study this topic, this doc is a work in progress, please let us know for any suggestion.

Now by far the best book (although I think I could have created a better version) for studying for programing interviews is: "Cracking The Coding Interview"

Remember that actors interact only using message passing. In order to check actors behavior you can do it through the messages sent to them and back from them. So how do you test actors? You send them messages :)
To test actors that communicate only with messages, you need to send it a message and get reply back and check it.
akka has a TestProbe valp=TestProbe(); // record incoming messages in queue so you can assert and verify them.
Creating actor system for tests: implicitvalsystem=ActorSystem("TestSys") valtoggle= system.actorOf(Props[Toggle]) // this is the actor we are going to test.valp=TestProbe() // this is the test client actor which will record the messages.
p.send(toggle, "How are you") // probe --> tested actor: how are you?
p.exepectMsg("happy") // assert result is happy.
To have the probe actor created for you: newTestKit(ActorSystem("TestSys")) withImplicitSender { // we are in probe actor.valtoggle= system.actorOf(Props[Toggle…

You see it's much easier than you think there exists a limit set of rules you should apply to most of the programming interview questions which involves algorithms and data structures. I have prepared a summary of them for you, just read below and get your tips for today.When you have no clue / Under panic attack => Brute Force!

If you don't have a clue, brute force the fu**** question! In most cases the question you are presented with has a brute force solution. Mention clearly that you are brute forcing it and say that the time complexity is O(n^2) or whatever it is. Then think where do you waste time in your brute force solution, try to improve that part, in many cases, this will get you closer to the actual answer.

By brute forcing you get to be familiarize with the problem better. A common theme for brute forcing means you are going to have a for loop inside a foor loop something like the below, so it's great to get familiarize with common bruteforcing snippets,…

We are a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for us to earn fees by linking to Amazon.com and affiliated sites.