There is very much an alternative. Looking at the execution of your code should never alter its fundamental performance the way otel is built to do. This was a solved problem at least a decade and a half ago, but the cool kids decided to reinvent the wheel, poorly.
OpenTelemetry won observability mindshare, but it is entirely the wrong architectural choice: by buying into its ethos your code is held hostage by the least stable otel monitoring library for your dependencies.
Sadly, there was always an alternative that no one took: dtrace. Add USDTs to your code and then monitor progress by instrumenting it externally, sending the resulting traces to wherever you want. My sincere hope is that the renewed interest in ebpf makes this a reality soon: I never want to have to do another from opentelemetry.<whatever> import <whatever> ever again.
Wait -- is it country of birth or country of citizenship? If I was born in Switzerland but held a Bangladeshi passport could I possibly use the former's priority queue?
I've suspected that there are consistency issues on RDS for a while now: if you push large quantities of data (e.g. 1MM+ rows) into a database quickly and then try to read the same data out on another connection, you'll periodically get null return sets.
We've worked around it by not touching the hot stove, but it's kind of worrying that there are consistency issues with it.
As good as the DailyWTF story is, it's not real. Coal is unfortunately cash settled.
Even oil, which is physically delivered settles physically in discrete locations. It would be pretty funny if someone delivered tankers full of oil to your office though lol.