You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Assuming I'm working with a greenfield project I'd choose to organize my subjects like Application.Group.Channel and attempting to be lazy to avoid more complicated configuration management:
For a single stream setup; the stream is setup with the single subject of ["Application.*"]
For a multiple stream setup; each group stream is setup with the single subject of ["Application.Group.*"]
If I'm using a single stream I'd create it outside of the application, with multiple streams I'd let each group be responsible for creating their stream and expect consumers to fail if they try to subscribe to group subjects that haven't been deployed yet.
To help with discoverability when multiple streams are being used, for example when I need to create durable consumers for queue subscribers, I'd require/assume the stream names will be the same as the Group from the subject names.
It might make sense to use multiple streams and keep "related subjects" together but I'm not sure if that's even necessary. I'm also wanting to hear about what other possibilities and setups I could use to use Jetstream with a distributed application.
When building a distributed application with Jetstream would it be better to have one stream for the application or multiple streams with one for each microservice or group?
What should I take into consideration when deciding how many streams my application will need to use?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Assuming I'm working with a greenfield project I'd choose to organize my subjects like
Application.Group.Channel
and attempting to be lazy to avoid more complicated configuration management:["Application.*"]
["Application.Group.*"]
If I'm using a single stream I'd create it outside of the application, with multiple streams I'd let each group be responsible for creating their stream and expect consumers to fail if they try to subscribe to group subjects that haven't been deployed yet.
To help with discoverability when multiple streams are being used, for example when I need to create durable consumers for queue subscribers, I'd require/assume the stream names will be the same as the
Group
from the subject names.It might make sense to use multiple streams and keep "related subjects" together but I'm not sure if that's even necessary. I'm also wanting to hear about what other possibilities and setups I could use to use Jetstream with a distributed application.
Beta Was this translation helpful? Give feedback.
All reactions