Queue vs log vs pub/sub, BullMQ, RabbitMQ and SQS vs Kafka and JetStream

The town crier calls it in the square, odd-job cards wait in a box at the shop, and the parish clerk keeps a numbered minute book.

In the village	In the system
the crier's call: whoever is in the square hears it, anyone at home misses it	pub/sub (steps 1–2)
an odd-job card taken by one helper and torn up when the job is reported done	a queue and its ack (step 3)
a card not reported done by evening goes back into the box	redelivery (step 4)
numbered minute-book entries: reading one leaves it in the book	a log (step 5)
full minute books are pulped after 30 days, read or not	retention (step 6)
each society's own bookmark; a new society starts at page one	a consumer's position (step 7)
one minute book per committee, each read by one member of a reading group	partitions (steps 9–10)

In real terms: before choosing a broker, write down who must see each message (one worker, every service, whoever is listening) and whether anyone joining later needs the past.

Breaks down when: you picture the minute book as the only copy. A log's readers are not taking turns with the book; any number read it at once, each at its own page.

Contrasting case: one service with a work queue and nobody else interested. A queue and a work-queue stream behave alike there; the choice only matters once a second reader or a late reader appears.

4.1 ExamHall: the proctoring event stream

EXH-1360: proctoring events went out on a core NATS subject. The audit service, deployed later, found nothing to back-fill. MR !1560 moves them to a JetStream stream kept 30 days, with one durable consumer per service. Grading jobs stay on BullMQ.

4.1 core subject   anti-cheat 5 · analytics 5 · audit (subscribed after #5) 0
4.1 JetStream      anti-cheat #1–#5 · analytics #1–#5 · audit (created after #5, deliver all) #1–#5 · stream holds 5

The subject delivered only to subscribers present at the time (step 2). The stream kept all five, and each consumer read them from its own position (steps 5, 7).

4.2 The three shapes, side by side

Six messages, readers A and B; in two rows B is away while #3 and #4 are published.

4.2 core, two subscribers             A 6 · B 6 · deliveries 12
4.2 core, queue group of two          deliveries 6 · distinct 6 · to both 0 · split between A and B varies
4.2 core, B away during #3–#4         A 6 · B 4 (#1–#2, #5–#6) · B missed #3–#4
4.2 JetStream, B's durable, away      B 6 (#1–#6) · missed (none) · order 1 2 3 4 5 6
4.2 JetStream, one durable, 2 workers deliveries 6 · distinct 6 · left 0

Plain subscribers each get everything; a queue group (subscribers sharing one group name, one member per message) splits them (step 8), but keeps nothing for the absent (step 2). A durable consumer, which the server keeps by name with its position, resumes where it stopped.

4.3 Redelivery and order

Message #2 is rejected (nak) on its first delivery; everything else is acknowledged. max_ack_pending caps how many delivered messages may await an ack at once.

4.3 max_ack_pending 5   deliveries #1 #2(nak) #3 #4 #5 #2(again) · handled in order: #1 #3 #4 #5 #2
4.3 max_ack_pending 1   deliveries #1 #2(nak) #2(again) #3 #4 #5 · handled in order: #1 #2 #3 #4 #5

With five in flight, #2 comes back after #5 (step 12). With one in flight, order holds, at the cost of throughput.

4.4 model: 3 partitions, group of 5   assigned m1:p0 m2:p1 m3:p2 · idle m4, m5
4.4 model: order per key              acct7 read as o1 o3 o6 (partition 0, one reader)
4.4 model: second group from offset 0 reads 6 of 6 · first group's offsets 3/2/1 unchanged by it
4.4 model: o3 fails, retried in place: partition 0 offset stays 1 after 3 tries · o6 behind it read: false · partitions 1–2 read 3 of 3

The model encodes the quoted Kafka rules: one reader per partition (step 10), order per key (step 9), a group per position (step 7), and one offset per partition (step 11).