The issue with things that client must not do is that they might still do them, and users don't care whose fault it is. It's important to have auxilliary mechanisms to mitigate these.

I've been in this situation, a clientside bug meant that different requests arrived with the same idempotency key.

In my case, updating the client would have taken weeks, in the best case scenario. Updating the backend to check for a matching request body would have taken minutes, maybe hours.

It took me a surprising amount of arguing to convince people that, even if it was a clientside bug, we couldn't let users suffer for weeks in name of "correctness".

I had a hunch it was power related because my PSU was nearly 10 years old and probably with just barely enough wattage. I bought a new one and all the buzzing went away.

IIRC when I was researching possible causes, beefy Ryzen CPUs were the most commonly mentioned in various forums and reddit threads.

In fact, I suspect that most hate firearm-related violence and have worked to stop/curb it, and were opposed by Kirk who undeniably unfairly got a taste of his own medicine.

Of course two wrongs don't make one right, and people can be more classy than this, but it's a totally understandable sentiment and response.

There isn't a scenario where, at scale, someone can offer a product that respects consumer rights and is successful, because it's too profitable to not respect consumer rights just like it wasn't in many other cases.

While for sure there's a lot of signal and value in monitoring auth rates per BIN per payload, flipping bits can be extremely disruptive and counterproductive. From doing the wrong operation to being fined by the schemes, it's a lot of risk for not a lot of gain when these fields can be tuned ad-hoc for the few card issuers that deviate from the standard/norm.

For sure the better dev team won there, but on the long run, especially once CUDA becomes the only way to do "professional real world work", I'd like the hardware company to sell the hardware and the software company to sell the software, to avoid a dominant market position that hurts consumers and the industry, which is forced to pay premiums to monopolists.

I'm a bigger fan of the approach that AMD had over the years, their software frameworks are open and hardware agnostic, which resulted in improvements for everyone and not just their customers (e.g. Vulkan which came from Mantle, games with FSR or TressFX run well on all hardware, those with DLSS or Hairworks don't) and enable competition that brings prices down.

IMHO it's mainly due to the popularity of the service/product. The concentration of bad actors and the vastness of the audience/userbase make the difference. If Signal was used in the same way, it would get the same attention.

Ultimately we don't know if they QA'd the changes at all, if this was data corruption in production, or anything really. What we know for sure is that they didn't have a good story for rollbacks and enforced staggered rollouts.

On a serious note, we have no way of knowing whether their update passed some QA or not, likely it hasn't, but we don't know. Regardless, the post you're replying to, IMHO, correctly makes the point that no matter how good your QA is: it will not catch everything. When something slips, you are going to need good observability and staggered, gradual, rollbackable, rollouts.

Ultimately, unless it's a nuclear power plant or something mission critical with no redundancy, I don't care if it passes QA, I care that it doesn't cause damage in production.

Had this been halted after bricking 10, 100, 1.000, 10.000, heck, even 100.000 machines or a whopping 1.000.000 machines, it would have barely made it outside of the tech circle news.

IHMO the experience, the pragmatism and the soft skills needed for a successful/productive informal architectural meeting are too rare for this solution to work consistently.

Personally I've abandoned all hope and interest in software architecture, while on paper it makes a lot of sense, in practice (at least in what I do) it just enables way too many people to throw imaginary problems in the mix, distracting everyone from what matters with something that may eventually be a concern once/if a system hits a top-1% level of criticality/scale.

In my experience this is normally due to either how the card machine provider has set up the device or due to the lack of certification of the mobile wallet functionality on the "acquirer" backend ("host") that speaks to the card schemes.

It's annoyingly tricky to get the end-to-end transaction working properly across all schemes, all payment methods and devices. Different card schemes support different "payment kernel" parameters and have different certification requirements.

It could also be an attempt to save money on transaction fees, amex is generally significantly more expensive for merchants.

>Note that that’s a best-of-five measurement, so I’m allowing the file to be cached. Who knows whether Linux will allow all 13GB to be kept in disk cache, though presumably it does, because the first time it took closer to 6 seconds.