Open gedw99 opened 1 year ago
I've never heard of marmot before but it looks very cool. I have often thought about what to use to eventually scale out, and yes, you are correct, the SQLite databases are the only thing that's persisted and somewhat hard to scale out. The attachment files are easy: just shove them into some S3-compatible storage.
I will keep this ticket open as "scale ntfy horizontally", and will revisit marmot (and others) when I get to it. It may become urgent quickly, but right now it doesn't look like ntfy.sh is in trouble yet.
RQLite is the other option for SQLite btw.
pro and cons for each though .
I looked at rqlite too a while ago, thinking it would be an easy drop-in, but it's an entirely different protocol. It's SQLite-over-HTTP, and it doesn't give me horizontal scalability (i.e. it won't be able to handle more traffic). It only give me HA across multiple nodes. (This is according to the rqlite author and the FAQs).
what about a federated method? your main one receives the alert and sends it on to a list of federated until one of them replies its sent/stored...main reason im thinking this way is I have a homelab instance setup thats idle 90% of the time, and i'd love if ntfy.sh could take advantage of that with my permission,. as a feature it means larger services could look at spinning up 4 or 5 instances and using dns round robin maybe...
bump
https://github.com/binwiederhier/ntfy/blob/main/server/webpush_store.go Uses SQLite which is great but provides no HA, DE or scale out.
scale it out with marmot. Nats is embedded so there are no new binaries to worry about. It can be embedded itself.
https://github.com/maxpert/marmot