sbov

Depends on the project. We have some that use PostgreSQL backed queues. Some using Redis. As you get more traffic RDBMS resources are precious - wasting them on queues starts to become a poor tradeoff. Redis is so generally useful we tend to use it on most projects anyways, so it doesn't add another moving part. And we tend to be really conservative about adding new things to our production environment, and despite that Redis has found a home in our stack.

Note that the GamerNexus review of the 3950x didn't include their compile benchmark test, at least on Youtube.

And if the algorithm came out with the reverse result - an 80 female/20 male split, then the right-leaning opinion would call the outcome impossible (tech does have a strong left-wing bias!). I'm not sure your theoretical example proves anything except most people won't believe reality even if it smacks them in the face.

Your solution seems to assume only one thing will be accessing what is being mutated at once. If another thread comes in and gets a cart (e.g. maybe the user reloads the page) and they aren't waiting on the operation to be processed anymore. If you remove it from the queue after a few seconds of failure then fine. But if the point is "self healing" it presumably hangs around for a while.

You have to deal with this to some extent in any webapp that has more than 1 OS thread or process. But if you're keeping actions around for minutes or hours instead of second you're going to have to account for a lot of weird stuff you normally wouldn't.

If you really wanted something like this, I would think you would want a concept of "stale" data and up-to-date data. If a process is OK with stale data, the service can just return whatever it sees. But if a process isn't OK with it (like, say, checkout), you probably need to wait on the queue to finish processing.

And since the front end may care about these states, you probably need to expose this concept to clients. It seems like a client should be able to know if it's serving stale data so you can warn the user.

Maybe I'm mistaken.

Yeah, most of Venice's problems are due to pumping water from the aquifer under the city.

My assumption has always been that the "Pro" line is aimed at content creators. Because in lots of professional work you would want a plethora of ports which Apple doesn't give you.

When they started removing ports I use I switched to a Thinkpad T-series. It's been the perfect laptop for my use.

> If your system is extremely simple this may not be worth it. But you could say that about anything in the article, really.

I don't know. The level of complexity this introduces seems to be way higher than anything in the original article.

E.g. for placing something in cart, its not only the next page that is reliant upon it, but anything that deals with the cart - things like checkout, removing from cart, updating quantities, etc. Adding to cart has to be mindful of queued checkout attempts. And vice versa. It sounds way messier than the comparatively isolated concepts such as CI, DI, and zero downtime deploys.

Async communication certainly seems desirable across subsystems that are only loosely connected. E.g. shopping, admin, warehouse, accounting, and reporting subsystems. But by using asynchronous comms you're actually introducing more state into your application than synchronous comms. State you should be testing - both in unit & integration tests (somewhat easy) and full end-to-end tests (much more expensive).

I'm sure Amazon has all sorts of complexities that are required at their scale. But you can heavily benefit from the techniques in the OP even if you aren't Amazon scale.

It's certainly fairly simple to use queues for straightforward, independent actions, such as sending off an email when someone says they forgot their password. It's less obvious to me how your proposal lines up with things that are less so. Such as a user placing an order.

So I'm having trouble envisioning how your system actually works. At least in the stuff I work on, realistically, very few things are "fire and forget". Most things are initiated by a user and they expect to see something as a result of their actions, regardless of how the back end is implemented.

This was my thought. I wish they spent that area on giving me more cores. But whatever.

I hope AMD starts using more than 1 chiplet for laptops. Until they do an AMD laptop is limited to 4 cores.

Also, most languages are not sinking ships. Certain uses of them are of course. But even languages this site hates, such as C, C++, C#, and Java have very long lives ahead of them for certain uses. Obviously C++ vs Rails... well, you're going to be out of a job. But if you were using C++ for the sorts of things you would have used Rails in 2009 you were already a decade or so behind the curve.

That's when you buy it. I'm not an accountant, but AFAIK if someone gave you stock for performing a service you would pay taxes on it at that point in time. Then if you sold it you would pay taxes on the difference in value.

I think the key might be that the IRS is viewing bitcoin as a payment for the service of mining.