DISPATCHConsumers are pull-based, meaning the services consuming data from them have to ask the system for the next available message. This means you can easily scale your services up by adding more workers and the messages will get spread across the workers based on their availability.
--sampleoptions on the CLI as this is not prompted for at present, everything else is prompted. The help in the CLI explains each:
ORDERS.received. Remember the Stream subscribes to
ORDERS.*, this lets us select a subset of messages from the Stream.
$ nats con info ORDERS DISPATCH -j | jq .config:
MONITORConsumer is push-based, has no ack and will only get new messages and is not sampled:
$ nats con info ORDERS MONITOR -j | jq .config:
Statesection will be shown later when discussing the ack models in depth.
Request()feature, but the
natsutility has a helper:
nats reqcannot ack, but in your code you'd respond to the received message with a nil payload as an Ack to JetStream.
MONITORConsumer we have no Acknowledgement.
ORDERS.processedthis helps you distinguish what you're seeing in a Stream covering a wildcard, or multiple subjects, subject space.