Overview on what MQ is/ does?
Since you certainly do not want something shallow, you find it here: https://martinfowler.com/articles/201701-event-driven.html A more hands on example is what we do for Lukas Nuelle, in the rough here: How to prevent dual writes
How does that work in B1? How does it work in B1, we likely would these days use the Progress Native Kafka Integration, but needs to be vetted: https://www.progress.com/tutorials/jdbc/streaming-your-data-from-openedge-to-kafka https://www.progress.com/blogs/build-an-etl-pipeline-with-kafka-connect-via-jdbc-connectors
Why one would use that?
APIs provide on demand access and often are in front of a DB, the client only gets data if it requests Event Systems like Kafka provide a stream of updates when they happen, the client normally stays connected forever or long periods of times and listens for the updates, as such a real time experience can be established modern DBs often have an API or even an Event Interface included https://www.postgresql.org/docs/current/sql-notify.html https://www.mongodb.com/docs/drivers/node/current/fundamentals/stable-api/ For older DBs, one often has to write a server/service that sits in front of it, that provides an API system and might delegate the event emitting to something like Kafka. however even if a DB or service can emit events itself, using Kafka or another messaging service in between allows for scalability and durability, e.g. messages are stored on the Kafka instance, if a listener goes offline and comes back online, the listener can replay messages/events that were distributed while being offline. A message bus with a long duration of replay can also be used as such to persist data, e.g. for 24h to enable batch processing at the end of day or such