fizwhiz

I'm sorry but this was easily the most pretentious book I've read all year.

Why hasn't their stock plummeted like Google's?

FWIW they mention this at the bottom of their document

> Just like BlazingMQ’s other subsystems, its leader election implementation (and general replicated state machinery) is tested with unit and integration tests. In addition, we periodically run chaos testing on BlazingMQ using our Jepsen chaos testing suite, which we will be publishing soon as open source. We have also tested our implementation with a TLA+ specification for BlazingMQ’s elector state machine.

> This section explains the leader election algorithm at a high level. It is by no means exhaustive and deliberately avoids any formal specification or proof. Readers looking for an exhaustive explanation should refer to the Raft paper, which acts as a strong inspiration for BlazingMQ’s leader election algorithm.

So their own homegrown leader election algorithm?

> BlazingMQ’s leader election and state machine replication differs from that of Raft in one way: in Rafts leader election, only the node having the most up-to-date log can become the leader. If a follower receives an election proposal from a node with stale view of the log, it will not support it. This ensures that the elected leader has up-to-date messages in the replicated stream, and simply needs to sync up any followers which are not up to date. A good thing about this choice is that messages always flow from leader to follower nodes.

> BlazingMQ’s elector implementation relaxes this requirement. Any node in the cluster can become a leader, irrespective of its position in the log. This adds additional complexity in that a new leader needs to synchronize its state with the followers and that a follower node may need to send messages to the new leader if the latter is not up to date. However, this deviation from Raft and the custom synchronization protocol comes in handy because it allows BlazingMQ to avoid flushing (fsync) every message to disk. Readers familiar with Apache Kafka internals will see similarities between the two systems here.

"a new leader needs to synchronize its state with the followers and that a follower node may need to send messages to the new leader if the latter is not up to date". I thought a hallmark of HA systems was fast failover? If I come to your house and knock on the door, but it takes you 10mins to get off the couch to open the door, it's perfectly acceptable for me to claim you were "unavailable". Pedants will argue the opposite.

Lots of haters on the part1 segment of this article wondering "wtf does this VP even do?!"

> I have friends who are line managers at larger companies who take home more than I do in my current role

I wonder if this is the "liquid" portion of Emily's comp. If it's the "total" comp then that tells me a VP Eng at a Series D startup makes < $400k all in??

What's min-maxing?

These roles likely comprise less than 5% of all engineers at big tech companies so I would be pretty surprised if such a book exists.

nit: Cockroach was founded by a Xoogler but there's no public evidence that they were on the Spanner team at any point.

With idempotence, you shift the problem from "deliver X exactly once" to "make it seem like X was delivered exactly once". In most systems, exactly-once is really "effectively exactly once".

Exactly Once = At least once + Idempotence

OT: Sorry to hear what happened to you at Twitter (:

Damn dude what did you do? Sell Ads to teens?