Brokerless Messaging with NetMQ
NetMQ removes the broker requirement, not the need to define queues, backpressure, socket ownership, acknowledgement and reconnect semantics.
No broker does not mean no queue.
NetMQ implements ZeroMQ-style messaging in C#. Because there is no separate RabbitMQ or Kafka service, part of the reliability contract moves into the application.
Messaging patterns
NetMQ provides Request/Reply, Publish/Subscribe, Push/Pull and Router/Dealer. These are stateful messaging contracts rather than thin wrappers over TCP.
Why brokerless can be useful
Removing a central broker can reduce deployment complexity and an intermediate network hop. It also means durability, replay and centralized queue management are not automatically provided.
Socket ownership
NetMQ sockets are designed around thread ownership. I prefer a single poller/event loop to own the socket while other threads communicate with that owner through controlled boundaries.
High-water mark is backpressure
Producer and consumer rates eventually diverge. High-water mark limits queue growth; when reached, the application needs an explicit backpressure policy.
PUB/SUB accepts loss semantics
A subscriber that is disconnected or not yet connected can miss messages. That can be acceptable for replaceable telemetry and unacceptable for commands. Pattern choice must match business semantics.
TCP ACK is not application acknowledgement
A successful transport send does not prove that the remote application processed a message. Processing confirmation, when needed, belongs to the application protocol.
Poller and event-loop design
Long CPU or blocking I/O work should not execute inside the socket-owning poller. The event loop itself is a capacity boundary.
Failure and reconnect
Reconnect behavior should define queue retention, duplicate handling, message expiry and shutdown ordering. Without idempotency, transport recovery can produce duplicate business effects.
I use brokerless messaging when components need a lightweight transport and the application can explicitly own durability and recovery. When durable replay is the primary requirement, a broker may be the better abstraction.
References
- NetMQ project repository
- ZeroMQ Guide