A message queue lets application components communicate without connecting directly. Producers send messages to the queue, which delivers them to one or more recipients. This decoupling supports faster communication, improved scalability, and new features without requiring downtime. section 21.0
Clients connect to a queue to publish or receive messages. Queue protocols are optimized to transmit request bytes and return acknowledgments quickly, while avoiding complex message processing. This allows high message throughput and shorter-lived connections than direct database requests. section 21.1
Choose the queue pattern according to the workflow:
- Use Redis channels when publishers broadcast messages and each subscriber should receive a copy. section 21.1
- Use NATS subjects to identify message types, such as events.todo.newitem, between containerized services. section 21.2
- Move work such as saving a to-do item behind a queue when direct database connections could become a scalability limit. section 21.2
- Plan subscribers as part of the feature: publishing without a subscriber can leave expected application behavior missing. section 21.2
Run a local message flow
Create a Docker network, start Redis, publish “ping” on channel21, and attach a subscriber. The subscriber displays messages as they arrive. For an application workflow, start NATS with Docker Compose, publish a new-item event from the web service, then run a subscriber on events.todo.newitem to verify delivery.
