Okay, so it wasn’t tomorrow.
You take your first step in understanding the pub/sub mechanics of a message store by learning about stream names.
Most of the streams you’ll see will be of the form:
<left of the first dash>-<right of the first dash>
You can give them more meaningful names:
<category>-<identifier>
You’ll typically use UUIDs as identifiers in streams, and they have dashes in them. The delimiter between category
and identifier
remains the same. Left of the first dash is the category, and right of the first dash is the identifier.
If you had an account with identifier 123
, the name of the stream where the events recording its state would be account-123
. Commands sent to the same account would be in the stream named account:command-123
. That colon in the category separates a list of category modifiers from the category. Topic for another time.
Categories are streams too
If you took all the events with the same category, for example account
, you would form another stream whose messages are ordered by their global_position
. You would find events for every account in the system interwoven with each other in this stream.
A category stream won’t help you much for getting the state of any particular account, but if you want all account events, use the category stream. In fact, this is what consumers in Eventide do.
Categories enable pub/sub
Whatever produces events related to accounts will put them into streams with category account
and thus into the account
category stream. So if you want account-component
to do something, and you want to know the result of it doing that thing, you’ll look for that result in the account
category.
And so will everything else that asks account-component
to do something.
You’ll need a way to distinguish events resulting from your requests from all the rest.
That involves metadata
, and we’ll cover it next.