What's a Message Bus?
The moment you have two programs that need to work together, you have a new problem: how do they talk?
One program finishes a chunk of work and has to hand it to another. Or something happens over here that three other things need to know about. Or a job needs doing and you do not care which worker picks it up, only that one of them does. None of that works if the programs just call each other directly and hope the other one is awake and listening. You need something in the middle.
That something in the middle is the idea behind a message bus: a shared channel that programs drop messages onto and read messages off of, instead of wiring themselves directly to each other. It comes in a few basic shapes, and the shapes matter more than the brand names.
A queue is a to-do list. One program drops a task on it; another picks the task up, does it, and marks it done. Each task gets handled once, by whoever grabs it first. This is how you spread work across a pile of workers without any of them stepping on each other.
A broadcast (you will also hear “publish/subscribe,” or pub/sub) is an announcement. One program says “this happened,” and every program that signed up to listen gets its own copy. Nobody competes for the message; everybody just hears the news. This is how you let one event ripple out to many places at once.
A log is a diary everyone can read. Entries get written down in order, and they stay written. A reader can start at the beginning, or pick up where it left off, and replay anything it missed. This is the shape behind tools like Kafka, and it is what you reach for when “what happened, in what order” has to survive.
A signal is a tap on the shoulder. No real content, just “hey, now”: wake up and go check something. It is the cheapest message there is, and sometimes it is all you need.
Underneath the names, every one of these is answering the same question (how do separate programs coordinate?) with a different set of tradeoffs. Fast or durable. One listener or many. Remembered or forgotten the instant it is read. There is no best bus, only the one whose tradeoffs match what your programs actually need.
That is the whole trick, and it is worth holding onto, because the next time someone says “queue” or “Kafka” or “pub/sub” or “message bus,” they are not describing four unrelated technologies. They are describing four answers to one question. Once you can see the shape, the brand name stops doing the work.
Which is exactly the lens you need for a stranger claim: that a perfectly ordinary GitHub issue tracker can be one of these buses, and a surprisingly good one.
Learn more
A few clear starting points if you want to go deeper:
- AWS, “What is a message queue?” — the queue shape, explained simply.
- ByteByteGo, “Messaging Patterns Explained: Pub-Sub, Queues, and Event Streams” — a good visual tour of all of these.
- Apache Kafka, “Introduction” — the log/stream shape from the project that made it famous.
- Enterprise Integration Patterns, “Messaging” — the canonical catalog, if you want the formal version.