Falsehoods Software Developers Believe About Writing Articles:
1. Using a cliched headline style adds authority to your article.
In all seriousness, this article is just a list of unsupported assertions. I agree with many of them because of my own experience. But those with which I disagree, there is nothing to convince me. A much more useful article would explain nuance, risks, consequences, handling strategies.
For example, "Events will arrive in order". What causes that not to happen? Does the number of events, technology used affect it? What are the consequences of believing they will arrive in order, and then discovering they don't? What are the tradeoffs in designing the system to make it happen less frequently vs tolerating them arriving in any order?
Chalk me up to believing a falsehood, what's the failure case where such a protocol breaks down? Is this a "More than 50% of nodes in byzantine fault failure mode" situation, or a realistic scenario?
I think the text is meant as a checklist you can use to apply to some system, not a list of impossibilities.
For example:
> Events will arrive in order, even if specified by the producer contract
This reminds me of a system I worked on. It used FIFO queues, but even with very low throughput we were getting out of order records on our database.
It turns out there was a rogue worker re-queueing some items into a non-FIFO standard queue that CAN deliver out of order stuff, and that was messing things up.
We were trusting the producer contract, which works well enough, but there were guarantees we needed to make on _OUR_ side to ensure proper ordering all the way through.
blowski|1 year ago
1. Using a cliched headline style adds authority to your article.
In all seriousness, this article is just a list of unsupported assertions. I agree with many of them because of my own experience. But those with which I disagree, there is nothing to convince me. A much more useful article would explain nuance, risks, consequences, handling strategies.
For example, "Events will arrive in order". What causes that not to happen? Does the number of events, technology used affect it? What are the consequences of believing they will arrive in order, and then discovering they don't? What are the tradeoffs in designing the system to make it happen less frequently vs tolerating them arriving in any order?
xnorswap|1 year ago
xnorswap|1 year ago
https://en.wikipedia.org/wiki/Atomic_broadcast
Chalk me up to believing a falsehood, what's the failure case where such a protocol breaks down? Is this a "More than 50% of nodes in byzantine fault failure mode" situation, or a realistic scenario?
alganet|1 year ago
For example:
> Events will arrive in order, even if specified by the producer contract
This reminds me of a system I worked on. It used FIFO queues, but even with very low throughput we were getting out of order records on our database.
It turns out there was a rogue worker re-queueing some items into a non-FIFO standard queue that CAN deliver out of order stuff, and that was messing things up.
We were trusting the producer contract, which works well enough, but there were guarantees we needed to make on _OUR_ side to ensure proper ordering all the way through.
protomolecule|1 year ago
inopinatus|1 year ago