Regarding the first bit of the article, is there an outline anywhere showing a smart way of handling the Twitter example given?
In fact, the smart way to handle it likely depends on the needs/business constraints at the time it was implemented. For instance - If I'm following Bieber on 9/15/2015 @ 3:00 PM EST, and he tweets, must it be a permanently held "fact" that I saw this in my feed? If I stop following him 6 months later, but sit there in my phone app (or web app, whatever) and scroll back far enough, should the tweet show? And when that tweet happened, was it potentially true that all of his followers should potentially have gotten in-app notifications (or at least, the possibility of this exists, depending on some algorithm so that people's phones aren't getting a never ending stream of notifications, but something can decide which tweets are important enough, or have been paid, to cross a threshold that says "notify"?)
"Edge"ish case: He tweets, we use a pub/sub or information bus type system to publish this fact. I'm following at 3:00 PST on the dot, precisely when he made the tweet, but I happened to unfollow 20 seconds later. Some async job is processing the "deliveries" through 30 million followers, and by wall clock time is faced with this decision after I've unfollowed to put this in my inbox or not. What happens?
Anyway, long winded way of saying I think it's more fun to explore options than to search for a textbook answer.
"I just started my twitter clone yesterday. I built a prototype in rails last night after chugging red bull! Each tweet is just database row with a giant many-to-many relationship. We're at 30 users already! I told my mom about it and she got a bunch of her coworkers to sign up.
We should probably cache or precompute some feeds, but we're fine for another 2,000 users."