>If 10000 Twitter users with 1000 followers each send a tweet, that's 10000000 messages hitting queues.
if your system design is actually done that way, i.e. that that amount of actual msgs, in one shape or another, hitting actual queues... well, you would definitely inflicted "scale" onto your system. It is like for any powerful data system there is always possible to make a cartesian query that will kill it :)
You've "inflicted scale" but with constraints that makes it reasonable to handle:
As long as you first write the tweet to a durable canonical datastore, you can recover from the loss of any queue for individual users by re-processing the timelines of the accounts they follow. Hence you don't need those queues to be particularly durable. You can afford to cache a lot of data in memory, and write compressed updates to disk lazily. How durable you make the system is a tradeoff between the frequency of node failure and the cost of recovering from it vs. the cost of more nodes to handle lower write rates.
The alternative is to pull, but then you inflict polling costs + a lot of caching hassle.
But at some point you will need to send a push notification to my devices. You're going to do that in the same process that is reflecting the message to all recipients?
if your system design is actually done that way, i.e. that that amount of actual msgs, in one shape or another, hitting actual queues... well, you would definitely inflicted "scale" onto your system. It is like for any powerful data system there is always possible to make a cartesian query that will kill it :)