In 2015, in one project one "clever" co-worker decided to use "zeromq" in project where is the guarantee of delivery was must. I think that because he wanted to attach this technology as fancy stuff in his cv. Later he left and we had to rewrite message sending and converted to basic http.
(Yes to the earlier post - had a similar experience with an early metrics system for Twilio in 2012-2013)
The 1st issue is that ZMQ implementations generally have an IO thread handling all socket IO. REQ/REP patterns tend to work out just fine, because the client is going to wait for a reply from the server. But things like PUSH/PULL become...harder to follow. You can push things in the client, but how do you know when they've flushed out of the IO thread and made it to the server? Those sorts of things matter when shutting down a process, running integration tests, etc. In contrast, with an HTTP request, you're basically always doing REQ/REP, and so you know when the data has been pushed.
The 2nd issue is that ZMQ implementations tend to be harder to observe / operate than a more common path like HTTP requests. (HTTP requests can go through a load balancer, have standard response codes, use headers for authorization, etc.) For these reasons, I've tended to avoid ZMQ ever after -- it seems like often, you're best off either using REST or GRPC if by HTTP, or raw TCP if it's purely a data push kind of operation (e.g. forwarding structured logs, with framing, to a remote TLS endpoint).
About the same time, I used zeromq in a project for similar reasons:
- I wanted easy message framing
- I didn't know much about networks
- HTTP servers that can be embedded in C++ aren't great, and I didn't know anything about HTTP
- It is nice that you can ignore application startup order if you don't care much about reliability, which I didn't
If I knew then what I know now, I would probably have picked something else. For one, I couldn't make it integrate with my main event loop, so I had it block in another thread, and that caused a problem of inter-thread communication that was nearly as bad as the original problem, for me as an inexperienced noobie.
> I couldn't make it integrate with my main event loop
You can get a file descriptor from ZMQ to use with your own event loop (depending on your event loop of course). I have done this successfully in the past with an epoll (iirc) based event loop.
The documentation is at [1], the ZMQ_FD option. You do have to read the instructions very carefully though.
