When you have two systems that need to communicate, the default for 90+% of companies is to use a shared database. (thread) #dev #programming #architecture #softwarearchitecture
Most never move off of this model, but it has disadvantages that go along with the ease of sharing data. Applications lack encapsulation and cannot adapt their data designs to suit their unique requirements.
Usually the next approach is to treat applications just like components, with exposed public APIs. However, this can result in increased down time since direct API communication between applications means if any is down, the whole thing is down.
So the next approach is to use message queues. This allows decoupling of commands/messages from their execution, which also allows for absorption of some downtime by downstream services/apps. With 2 apps, it looks like this: 
However, as additional applications are deployed, each one needs to have its own queue, and each existing application must be updated to also write to the new app's queue (as required, if it needs the updates, etc.). With 3 apps, you can see the problem growing:
It's at this point that a message bus solution starts to make sense. Commands and events can be sent to a common message bus, and other applications can subscribe to whichever messages they care about. Existing apps do not need updated as new ones are deployed.
You can use a cloud-based tool, such as Amazon SQS or Azure Service Bus for this purpose, as well as many other non-cloud options. While not a panacea, it does offer substantial benefits over API-based and simple Queue-based systems of more than 2 nodes. /end
