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
I use Jetstream for a couple of services that I wrote for indexing likes / posts / etc. I was wondering if it's possible to have a stateless config for Jetstream that uses a consumer that doesn't write events to disk for replay. Might be nice to quickly scale up a bunch of instances that are just live tailing.
It should be pretty easy to do:
Add a field (single flag or custom config struct) to the firehose Consumer, skip event persists in the RunSequencer goroutine.
Add logic to bounce any clients that request a cursor before the current time.
Alternatively a "retention" config could be added to periodically clean the local RocksDB instance. And if the retention was set to 0 (seconds/minutes/days or events) it would skip the consumer DB entirely.
This should be a good start. As there's only one FH consumer per Server instance, I don't think the current code could support transparent subscriber requests to backfill.
I've got some cycles to work on this shortly, I don't have any urgent need for stateless, more of a performance experiment.
Let me know what you think!
The text was updated successfully, but these errors were encountered:
Hey all,
I use Jetstream for a couple of services that I wrote for indexing likes / posts / etc. I was wondering if it's possible to have a stateless config for Jetstream that uses a consumer that doesn't write events to disk for replay. Might be nice to quickly scale up a bunch of instances that are just live tailing.
It should be pretty easy to do:
RunSequencer
goroutine.Alternatively a "retention" config could be added to periodically clean the local RocksDB instance. And if the retention was set to 0 (seconds/minutes/days or events) it would skip the consumer DB entirely.
This should be a good start. As there's only one FH consumer per Server instance, I don't think the current code could support transparent subscriber requests to backfill.
I've got some cycles to work on this shortly, I don't have any urgent need for stateless, more of a performance experiment.
Let me know what you think!
The text was updated successfully, but these errors were encountered: