I have a question, hopefully it doesn't sound too stupid. Basically my question is: do you have any recommendations for reading about "concurrency" but at a hi

I have a question, hopefully it doesn't sound too stupid. Basically my question is: do you have any recommendations for reading about "concurrency" but at a higher level than "concurrent programming" and less formal than "distributed systems" algorithms? Here's an attempt at explaining what I mean: Suppose I worked for a company which mostly writes web apps in python. They don't write much multi-threaded code. They don't write native desktop graphical apps or do "systems programming". So books about "concurrent programming" with threads, or in go/scala/clojure/erlang etc seem, superficially, slightly irrelevant. Also, books about formal distributed systems algorithms seem, superficially, slightly irrelevant. But "concurrency" is still highly relevant! It's just at a higher level than is meant by "concurrency" in a programming language and it's not as formal or regular as is usually meant by "distributed systems". What I mean is: the company handles concurrent HTTP requests resulting in concurrent database transactions; celery tasks might also be running at the same time; message-queue type problems come up frequently; they are increasingly tending towards a "service-oriented" architecture which is inherently concurrent; and, at the end of the day, all the higher-level "business logic" is some sort of emergent property of a complex, and concurrent, underlying system of apps communicating via HTTP, with asynchronous background tasks, etc. Wise senior programmers say: "Oh, you're going to need to apply some row-locking there.". Wide-eyed junior programmers say: "Oh yes, of course" and wonder, "What should I be reading to know this?". What should they be reading? Also, how the hell do people diagram this stuff in order to talk about it? Google searches tend to end up either in UML languages that seem to be unfashionable (but might in fact be just the right thing?) or in academic CS papers that seem to be uninfluential. But there must be something better than those pessimistic paragraphs from No Silver Bullet: > Software is invisible and unvisualizable... The reality of software is not inherently embedded in space... As soon as we attempt to diagram software structure, we find it to constitute not one, but several, general directed graphs superimposed one upon another. The several graphs may represent the flow of control, the flow of data, patterns of dependency, time sequence, name-space relationships... In spite of progress in restricting and simplifying the structures of software, they remain inherently unvisualizable, and thus do not permit the mind to use some of its most powerful conceptual tools. This lack not only impedes the process of design within one mind, it severely hinders communication among minds.