- at any one time we need to store…
Not a problem , EventStoreDb is made for this - Streams need to eventually expire… after N days truncate…
you mean delete streams or truncate them ?- Truncation can be automatic ( though you will need to run scavenge to actually reclaim the space , this can be automated )
- Truncation for ESDB means in that stream remove events older than X (some time span)
- Deletion of stream is also an option, but not automatic you have to delete them it’s either a tombstone (the stream can not be recreated, or a delete where the stream can be recreated and the next appendend event will get the next revisions umber
- The sizes of each message s
nothing to say here
- The most important access pattern for read is to be able to efficiently retrieve all events from a stream- I.e. a
- not seeing an issue there,
- we may need to support hundreds or even thousands of concurrent readers.
- that will be a good reason to test performance of the database, memory & IOPS mainly and the system as a whole
- Esdb has a concept of read-only replica https://developers.eventstore.com/server/v20.10/clustering/node-roles.html#read-only-replica that is used if the cluster is not able to keep up.
- that said , there are application patterns that might help in not having hundreds / thousands of readers but still achieve what you want .
1 Like