Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reliability, availability and scale – an interlude

afeinberg.github.com

Post reply on HN
Print view View original

11–12 of 12 posts

Re: Reliability, availability and scale – an interlude

#11

Post by IgorPartola »

Robin_Message wrote: post #10
IgorPartola wrote: post #8

Earlier quoted context omitted.

Any idea if there was any success with it?

I've found a reference to it in Jean Bacon's Concurrent Systems . She calls it "quorum assembly", but I can't find any other references with that name (slides on cl.cam.ac.uk are by her, or influenced by her work.) I'm afraid it is probably an idea that has been had many times. The write quorum (number of nodes you must talk to to do a write) must be > n/2. The read quorum plus the write quorum must be > n (otherwise…

Thanks for the details and the explanation. Makes a lot of sense.

Re: Reliability, availability and scale – an interlude

#12

Post by noonat »

_urga wrote: post #9

I have this idea in mind of a system where nodes are symmetrical and each node contains a vertically integrated stack, all within a single, evented process. So instead of having asymmetrical services (database, web server, workers, logging, messaging) spread across clusters of symmetrical nodes, one would have all of these services within a single process on a single core machine. Each node would be responsible for i…

I think the main problem with this approach is that different parts of your stack have different requirements. One part of your stack might require large amounts of RAM for efficient response times, but may be used infrequently, for instance. With a separate server, you can scale that part of the stack independently. If the whole stack lives in every server, you must sacrifice performance or money for that consistency.
Post reply on HN