Thank you for such an article. * In some systems I want to reply ASAP because a message is on the hot path, so the response is acknowledgement of persisting da

Thank you for such an article. * In some systems I want to reply ASAP because a message is on the hot path, so the response is acknowledgement of persisting data and an fsync to assure the request was saved and maybe an identifier so the progress of the request can be checked. I might want to send some work to background processes. * I feel systems lack end-to-end responsiveness. If you're polling with REST to see if something is finished then there's a problem with your design chosen by the kind of async you chose. * I feel async/sync nonblocking/blocking push/pull is orthogonal to everything in your system design and everything falls out from that decision. If only there was a way to map between the three. I am working in this space: I want async/sync to be something that can be seamlessly switched between and handled by the infrastructural plumbing and you can focus on the business logic. * I think systems design is actually a tree for performance reasons similar to Rust communicating between nodes is slow as it introduces round trip times.