function61 / eventhorizon Goto Github PK

Dynamo dB is cool but I was wondering if you are tempted to reconsider also supporting self stores too. So people can use AWS or local

genji is similar to dynamo dB in that it’s badger dB ( a kv store of sorts ) with a sql document dB on top.

been using if for a large project and it’s been ok. A few shaky edges but easy to work around until it’s better.
Speed is really great.

https://github.com/genjidb/genji

there is no HA aspects integrated however many have managed to use raft with badger dB for replication.

I am hoping this is of interest and if you want some help with it because the basis of event horizon looks in line with how I think CQRS is best used.

Benefits:

• Show really helpful debug information in the UI for events (like additional description for the field, possible values for enums etc.)
• Print the domain model associated with the event

Work needed:

• We already have event definitions as machine-readable JSON. Event Horizon would need to be able to access that somehow
• How to discover schema from event path? Schema to list stream patterns like /+/certbus?

The database itself could help us get universal timeseries metrics by counting encrypted (to exclude plaintext meta events like subscriptions etc.) log messages posted to stream patterns like:

Also we can get:

• all in aggregate (over all tenants)
• breakdowns by tenant

This can be done somewhat securely without needing access to encryption keys if we only use metadata (log entry # per stream), assuming streams are granular enough.

Ideas:

• "Table of contents" labels
• Progress bar for showing when the next screenshot comes

https://mobile.twitter.com/daveremy/status/1379470691360075776

If we ever wind up using a merkle tree -like data structure, the effects of bit flips should be considered as not to render the whole system inoperable like recently happened to a CT log: https://twitter.com/FiloSottile/status/1411583960115814401

Possible ideas: compute the payload hash twice? ECC memory?