The biggest blocker on scalability is actually that sometimes we load result sets that are too big for the browser (web interface). Should have that fixed in a week or two. How well the alerts scale really depends on your evaluation frequency, and how complicated the alerts (how many opentsdb queries does it make and how much processing does bosun have to do).
Currently everything gets relayed through bosun. This is primarily because we need to track the state of things for a few reasons:
1. For autocompletion etc on the graphing page
2. To trigger unknown when an instance of an alert (which is the alertname and opentsdb's tagset) has no data for the duration of the query (times 2 I think)
3. Bosun handles metadata itself
So there are a few things that I think OpenTSDB can do, but we didn't do because when we started development this stuff was just too rough (also, having it memory on the Bosun server makes it really fast). The other thing that impacts bosun's performance is that all reduction functions are done by bosun since OpenTSDB doesn't have these. So basically bosun has to slurp in all the data for most of the things it does since OpenTSDB doesn't support these operations natively. None of this is actually a real problem for us at our scale currently, but I thought you might find it interesting.
Also be sure to checkout scollector. It doesn't have to be used with Bosun https://github.com/bosun-monitor/scollector . It is a single binary so no dependencies, and also Windows is just as important as Linux and scollector runs natively on Windows as well. So I think there are some advantages there over tcollector.
Keep working away at OpenTSDB, bosun depends on it! :-)
Best,
Kyle