# Brokerless Messaging with NetMQ

> NetMQ removes the broker requirement, not the need to define queues, backpressure, socket ownership, acknowledgement and reconnect semantics.

- Author: Muhammet Ali Köker
- Language: en
- Canonical: https://alikoker.com.tr/en/brokerless-messaging-with-netmq
- Translation: https://alikoker.com.tr/netmq-ile-brokerless-mesajlasma
- Published: 2023-03-15T12:00:00+03:00
- Modified: 2026-08-30T14:55:00+03:00
- Type: article

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](/en/wiki/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](/en/wiki/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

## Cite This Work

Köker, M. A. (2023). Brokerless Messaging with NetMQ. alikoker.com.tr. https://alikoker.com.tr/en/brokerless-messaging-with-netmq

- BibTeX: https://alikoker.com.tr/en/brokerless-messaging-with-netmq.bib
- RIS: https://alikoker.com.tr/en/brokerless-messaging-with-netmq.ris
- CSL-JSON: https://alikoker.com.tr/en/brokerless-messaging-with-netmq.csl.json