Async ACID DB interfaces are so weird to me. I guess the async all the things! is frustrating since I’m brought in when things go boom, and folks that couldn’t

Async ACID DB interfaces are so weird to me. I guess the async all the things! is frustrating since I’m brought in when things go boom, and folks that couldn’t deal with parallelism are all up in concurrency and baffled by the result. I get going for throughput over transactional performance. But I don’t find that to be a practical goal in most business systems. In my experience every dev team that goes this route thinks “async is faster”, then gets confused when their latency shifts dramatically under load. Or their CPU usage jumps from 20% to all the CPU they can get. It’s especially odd with the (overly) microservices trend. A bunch of variable latency calls with a ton of network I/O overhead required to service 1 customer request. Shove those into tiny containers without any tuning and wooo! And probably exacerbating this is the trend to tack on afterthought async frameworks to languages like Python and Java, vs systems designed with it originally like Erlang and even Go. Folks familiar with Java or Python are suddenly lost troubleshooting. Stack traces, thread dumps, etc. become confusing. It’s not impossible, but the majority of developers are procedural themselves. I’ve only known a handful (out of thousands of contractors and employees) that were familiar with syscalls or could find useful info in a JFR. All that said, I’m looking at “big old company” workloads. Python for analytics, where it’s a friendly wrapper around C/FORTRAN, and Java for most everything else. And most async use is what I would call “YouTube driven development.” Ok, I’ve gone full “kids these days.” It’s interesting stuff, for sure. I just wish there were giant disclaimers around it for every library or framework. Troubleshooting async performance issues is my new troubleshooting C/C++ memory issues of old.