One part of system design interview is the back-of-the-envelope calculations. You have to estimate how many servers with which specs you need. I tried to find any manuals with calculations, bit didn't find anything better than https://servebolt.com/articles/calculate-how-many-simultaneous-website-visitors/
I would appreciate if you share your experience with such calculations.
Below I publish my humble effort to estimate Twitter (processing servers).

Preconditions and assumptions:

• 330 millions MAU;
• 5700 tweets per second in average;
• uniform distribution around the world;
• feed update requests are more frequent (say 10 times);
• we'd like to respond 95% of users for 100ms.

So we have about 60000 ( = 5700 * 11) QPS. According to the magic formula from the article 32 cores / 0.1s = 320 queries per second for 1 server. So we need 60000 * 0.95 / 320 = 178 servers

We also know that Twitter uses Redis for improve response speed. Feed cache for each user is stored there. Say each user has 500 tweets in this cache and each tweet is about 200 bytes. So we have 100Kb for each user. We don't know DAU value, but assume 50% of monthly users use Twitter every day. So we have 165 millions users per day, and it's 16Tb RAM (165000000 * 100Kb). So we have about 90Gb RAM for Redis if we have 178 servers. If we choose a server with 128Gb RAM Redis takes about 70% of memory, it's on the verge of critical value. 256Gb RAM will be better.
In the sake of service durability we have to replicate Redis. Say we need 2 replicas, it's 178 * 3 = 534 servers.

In the end we estimate storage. 5700 tweets per second, each tweet is 200 bytes. It's about 4Gb per hour, or about 100Gb per day. Let our servers have two weeks history in the fast access, after that we move data to archieve servers (we don't estimate them here). So we need 1.5Tb (of course in RAID).

Summary:
about 500 servers for real time processing, 32 cores, 256Gb RAM, 1.5Tb HDD RAID

P.S. We also need CDN for video, images and so on. They are also out-of-scope here.