Architecture
One daemon, three role-based endpoints, one allocator. Every moving piece is visible in a single diagram — and intentionally, no piece is optional.
Quicx is deliberately flat. A single daemonprocess owns the task queue, the worker pool and the PMAD allocator. Producers and workers are plain TCP clients that speak the same binary protocol — the first frame they send tells the daemon which role they’re playing.
There are exactly three horizontal message paths:
- producer → daemon
MSG_SUBMITlands a new task. The daemon responds with eitherMSG_OK {task_id}orMSG_ERROR {code}— always, within one round-trip.- daemon → worker
- Workers announce themselves with
MSG_READYand block reading. The daemon pushesMSG_TASKframes to the first idle worker. If the queue is empty, the daemon replies withMSG_WAIT. - worker → daemon
MSG_DONE {task_id}on success,MSG_FAILED {task_id, reason}on failure.MSG_HEARTBEAT/MSG_PONGkeep the socket from half-closing under long idle.
Why a single daemon?
Multi-node queues pay a tax in the form of leader elections, replication logs and consistent hashing. Quicx is optimised for the much more common case where your queue lives on the same host (or at worst, the same availability zone) as your producers and workers. One daemon is enough to saturate a 10 GbE NIC with short tasks and — because of PMAD — it does so with zero allocation jitter under sustained load.
Scaling horizontally means running multiple independent Quicx daemons behind a simple TCP load balancer. Because every socket is stateless at the protocol level (a submit is one request, one reply), there is no session to pin and no replication to coordinate.