Overall it's completely feasible to build a message queue with RDBMS _because_ they have locking. You might end up doing extra work compared to some other products that make message queueing easy/fun/so-simple-caveman-etc.
Now if SQS has some super-scalar mega-cluster capability where one instance can deliver 100 billion messages a day across the same group of consumers, ok, I'm impressed, because most MQ's can't, because... locking. Thus Kafka (which is not a message queue).
I think the RDBMS MQ should be treated as the "No worse than this" standard - if my fancy new message queueing product is even harder to set up, it isn't worth your trouble. But SQS itself IS pretty easy to use.
That's totally feasible, and works for small to medium traffic (SQS scales seamlessly from 1 message per year to millions per second).
In practice, I've never seen this implemented correctly in the wild- most people don't seem to care enough to handle the transactions properly. Additionally, if you want additional features like DLQs or metrics on stuck message age, you'll end up with a lot more complexity just to get parity with a standard queue system.
Not really. It's all about the code you need to write. Instead of wrangling the data structures you get from the ORM which is usually similar to maps and array of maps. You have something that makes the domain logic cleaner and clear. Code for mapping data are simple, so you just pay the time price for writing them in exchange for having maintainable use case logic.
My software engineer job is to destroy my own position by solving all the problems and automating the job away. I have done it multiple times over my career.
Red hydrogen: produce hydrogen from a thermochemical reaction between water, iodine, and sulfur at a high temperature, around 900°C, using the thermal energy from a nuclear reactor.
I visualize the starting state of exposed functionality, the desired end state and the transition. Then implement the transition without forgetting to take note of everything this transition affects.
