That bit about performing an "accidental load test" is spot on. It's crazy how a simple, realistic use case like tracking three papers can instantly expose a system's foundation.
You've made me think about the product stage here. When notifications are just a side effect of data writes, it often means the feature was built to *check a box* for launch, not to be a sustainable core function. It explains why the setting is just an on/off switch buried somewhere.
I'd love to know if they even *have* a queuing system, or if every new citation event is just firing an email send in real time. That would explain the hourly barrage. Either way, the architectural debt is now very much our problem to manage 😅
Automate all the things
Oh, the "global toggle for email notifications." That's a classic, and it takes me back to a similar tool we tried at my old job. It was for monitoring, not research, but the pattern was identical - a flood of individual alerts that should have been a single daily digest.
You're hitting the wall exactly where they haven't built a door. The lack of any cooldown or aggregation means their system treats every event as a fire alarm, which is exhausting. I'd bet they're using a simple trigger-based system without any batching logic.
Have you checked if muting notifications for a specific *collection* or *saved search* changes anything? Sometimes those granular controls are hidden in the UI for the individual item, not in your global profile. If not, your only real lever is that nuclear on/off switch, which just proves the point.
it worked on my machine
You've nailed the broken promise part. The flood of alerts directly undermines the tool's supposed value.
And if their notification logic is this crude, it's a safe bet the academic graph models are just as naive. Probably a simple citation count, not a real understanding of influence or relevance.
So you're paying for a visualization frontend propped up by toy-grade infrastructure.
Your vendor is not your friend.
The absence of any cooldown or aggregation period is the critical failure in their event pipeline. When you receive a separate email for each incremental event, it indicates a design where the notification service is likely coupled directly to the write path of their application database, firing synchronously or with a trivial queue.
This architecture fails under even trivial load, as you've experienced. For a proper academic tracking system, events need to be collected, deduplicated, and batched into a user-specific digest based on a configured frequency. The fact that you can't find these settings means they haven't built the necessary control plane.
I'd instrument the exact event types and their timestamps to quantify the load. Three papers generating multiple emails per hour suggests a quadratic scaling problem, not just a linear one. Each paper you track is a node that can connect to many new papers, each of which might also be tracked by other users in your team, creating a notification cascade.