Lesson 14 · Senior NATS practice

Queue groups, scaling, and consumer backpressure

How to reason about push vs pull, queue-group scaling, in-flight pressure, and when one subscriber shape stops fitting the workload.

Your win: explain how queue groups scale work, why push and pull are different control models, and how a senior engineer reads backpressure instead of only counting subscriber replicas.

The tempting wrong question

When a NATS consumer is too slow, the first instinct is usually: “Should we add more replicas?” Sometimes that is the right move. But if that is the only question you ask, you will miss the real system shape.

The stronger question is: what is the actual bottleneck — handler cost, downstream slowness, in-flight pressure, ordering constraints, or the fact that the workload wants pull-based control instead of server-driven push delivery?

In plain English Plain English: queue groups spread work across workers, but they do not remove slow-handler pressure or make every workload scale the same way.

The scaling rule Queue groups increase consumer parallelism, but sustainable throughput still depends on handler speed, flow control, and whether push or pull matches the workload shape.

Why the zeus pull consumer matters so much

The repo is mostly push queue-group JetStream consumers. That makes the zeus activity-log pull consumer especially useful as a teaching contrast. It shows a different philosophy: do not let the server push each event as fast as possible; let the client choose fetch size, batch shape, and pace.

That difference is not cosmetic. Push is a great fit for straightforward event handling. Pull is better when the consumer wants tighter control over batch work, pacing, and operational pressure. A senior engineer should be able to explain that distinction clearly, not just repeat the words “push” and “pull.”

Backend use case In this repo, most learner-owned subscribers use durable push queue groups, while zeus is the one pull consumer because the activity-log path benefits from explicit batch control.

Common mistake Assuming a queue group alone solves throughput pain without checking handler cost, MaxAckPending, downstream slowness, or whether the workload should be pull-based instead.

Consumers with a flow-control lens

Revisit the official consumer docs and compare them against the repo’s push-default shape and the zeus pull path.

→ JetStream consumers
→ Repo NATS map

Check yourself (from memory)

Q1. What is the strongest senior reading of queue-group scaling?

Queue groups help, but they do not erase real bottlenecks.

Why might a pull consumer be a better fit than a push queue-group consumer?

recall, then click to reveal

Because the client may need tighter control over fetch size, batching, and pace. Pull fits controlled batch work better than server-driven push delivery.

Want a “should this JetStream path be push or pull?” architecture drill? Ask me.

Sources. Official JetStream consumer docs; repo NATS map.