> That's a complete non-sequitur. It doesn't need to sequitur. You disagree with the (unimportant, arbitrary, and probably wrong) choice of "good" technology,

> That's a complete non-sequitur. It doesn't need to sequitur. You disagree with the (unimportant, arbitrary, and probably wrong) choice of "good" technology, for the (valid, fair, and important) reason of scalability. This is fine: whether a specific technology is fit for a hypothetical purpose is irrelevant to what I believe the article is saying. I don't read the article as saying "never talk about the technology behind scalability on HN or anywhere else," I read it as saying "people learn scalability from exemplars, so the way you improve overall scalability is by finding better examples, not discussing what's already out there." The reason we have use-cases of Kafka scaling is because LinkedIn[0] needed durable distributed pubsub, so they built it. When the linked article was written it was handling 500 billion events a day. That was kind of cool, because 500 billion is a big number, but also kind of shocking, because that was 68 daily events for each human being alive at the time. Perhaps in 2022 with the hindsight of the last decade, someone with different problems and priorities could approach scalability from a different angle and come up with something else that works better for them. [0] https://engineering.linkedin.com/architecture/brief-history-scaling-linkedin https://engineering.linkedin.com/architecture/brief-history-...