treenity

The problem

Build a publish/subscribe system where processes talk only through POSIX message queues. Producers write records to topics. Consumers subscribe by key prefix, receive the history and new records, and acknowledge what they have processed.

What I built

• A server with one main queue and one reply queue per client. Each topic has its own reader thread and worker thread. A single worker owns all changes to that topic, so replay and live delivery cannot overlap or lose a record.
• An append-only log per topic with offsets. Consumers acknowledge the next offset they want, so a reconnecting consumer resumes where it stopped.
• Graceful shutdown. The main loop blocks SIGINT and SIGTERM and waits in ppoll with the original mask. This closes the race where a signal arrives just before a blocking call. Topics stop with a poison pill, consumers are told to disconnect, and a 5-second alarm is the last resort.
• A hash map written from scratch (FNV-1a, chained buckets, rehash at load factor 0.75).

Decisions and trade-offs

One worker thread per topic

The consumer state needs no lock, and messages from one producer stay in order. The queue and the log still use a mutex. A very busy topic is limited to one core.

Bounded wait when a consumer queue is full

The topic waits at most 200 ms, then drops that message for that consumer. The wait also delays the other consumers of the topic, which is the cost of this choice.

Limits and next steps

The log lives in memory, so it does not survive a restart. A slow consumer can lose messages after the timeout. Both are listed in the README.