&gt; How is it easier to debug a message-passing architecture than a monolith?<p>You can observe the messages as they&#x27;re passed, which is usually enough. In my experience in Erlang, a lot of messages include a pid to reply to, so if you get an unexpected message, you can often see where it came from, and then look at the messages that came into that process, etc (or grep the code on likely identifiers). Erlang makes this pretty easy, you can also peek at the mailbox for a process to see what other messages it hasn&#x27;t read yet, etc.  This model works really well for me, because I&#x27;ve been using it for years to debug networking applications with tcpdump and friends: figure out what&#x27;s gone wrong over the wire, then you can figure out where it&#x27;s gone wrong in the code.<p>Added: I guess that doesn&#x27;t really address emergent behavior.  Most of the emergent behavior I&#x27;ve seen is really around overload conditions, most of the debugging around that is focused around finding the bottleneck(s) (which is usually a problem in a simple process -- you can tell which ones because they have a huge mailbox), why there isn&#x27;t enough back pressure (it&#x27;s usually because the senders aren&#x27;t waiting for confirmation, or aren&#x27;t waiting long enough, especially in combination with retries), and how to shed load instead of falling over (which is tricky)