Not at all.  Have you ever thought about caching Twitter?  It&#x27;s an archetypical example of a site that&#x27;s extremely difficult to cache well, which is the source of so many of its scaling problems.<p>Every person&#x27;s new feed is uniquely generated based on their followers.  That means you can only at best cache at the individual tweet level -- you still need to uniquely generate a news feed for each user.  This means that for every user you need to individually grab information simultaneously from the same high velocity tweets, while still being able to present information to each user uniquely based on conditions regarding how twitter should display tweets for that specific user individually. That&#x27;s incredibly demanding data wise because it makes horizontal distribution of load much more difficult --- a huge number of people are all making demands on the same set of data resources, and you can&#x27;t easily cache that data because of how real time and quickly updating it is.<p>In comparison WhatsApp on Erlang is basically just an example of extremely dramatic real time <i>horizontal scaling.</i>  Hosting hundreds of millions of simultaneous chats is relatively trivial in Erlang, given each one is operating under its own separately scalable chat process.  Since very few chats share data with one another, horizontal scaling is easy because you don&#x27;t have the issue of the same resource getting called simultaneously by millions of unique users at the same time, who all need that resource represented back to their own news feed in differently categorized ways.<p>tl;dr:  WhatsApp with the right technology is WAY easier to scale than Twitter.<p>---------------<p>(Speaking of the magic of Erlang for chat programs, this funny video &quot;for Ruby&#x2F;Node.js hipsters&quot; explains how Erlang does this magic quite well: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=rRbY3TMUcgQ" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=rRbY3TMUcgQ</a>) )