Inkbunny uses a similar scheme, as do many other sites. It works well enough when you have one database server and the indexes (if not the whole database) fit into RAM on one box. It's relatively simple to code, gives the user flexibility about keeping some things around for a while, and it's cheap to notify them when something new pops up - or to displaying a list of notifications (because you've done most of the relevant filtering ahead of time).
It's best when you have a low write count - or failing that, cheap transactions - and you clear old entries out regularly. It was that last bit that killed FA; they fell behind on writes. Probably didn't help that they were using spinning disks (I'm guessing it was too big for an SSD; that's why I've been so gung-ho about database size).
The alternative is essentially glorified polling. It may makes sense if you know you want most of the data that you're pulling (say, because you're looking at a dashboard of the latest posts), but in terms of computational effort it can be vastly more expensive. It works because once you get to that point, you're already planning to shard the database. Whether you see it as a form of Vectored I/O or MapReduce, it's the same concept - have several nodes query up to a certain date, and then do a final operation on those results.
Edit: And, you know what? Tumblr says an inbox system is the future (or was in 2012 - scroll to "Cell Design for Dashboard Inbox"). The architecture for furry art sites is effectively a one-cell system.
To be fair to FA, they haven't raised $85 million in funding - at least, it'd be news to me!
Inkbunny uses a similar scheme, as do many other sites. It works well enough when you have one database server and the indexes (if not the whole database) fit into RAM on one box. It's relatively simple to code, gives the user flexibility about keeping some things around for a while, and it's cheap to notify them when something new pops up - or to displaying a list of notifications (because you've done most of the relevant filtering ahead of time).
It's best when you have a low write count - or failing that, cheap transactions - and you clear old entries out regularly. It was that last bit that killed FA; they fell behind on writes. Probably didn't help that they were using spinning disks (I'm guessing it was too big for an SSD; that's why I've been so gung-ho about database size).
The alternative is essentially glorified polling. It may makes sense if you know you want most of the data that you're pulling (say, because you're looking at a dashboard of the latest posts), but in terms of computational effort it can be vastly more expensive. It works because once you get to that point, you're already planning to shard the database. Whether you see it as a form of Vectored I/O or MapReduce, it's the same concept - have several nodes query up to a certain date, and then do a final operation on those results.
Edit: And, you know what? Tumblr says an inbox system is the future (or was in 2012 - scroll to "Cell Design for Dashboard Inbox"). The architecture for furry art sites is effectively a one-cell system.