Adjectives are not requirements
The requirements that pick your architecture arrive as adjectives. It should be fast. It needs to handle a lot of users. It has to be always available. None of those constrain anything, so turn each one into a number you can be held to.
Four of them come up every time. Scale, as daily active users and what each one does, because that becomes queries per second, the count of requests your system answers each second. Latency, as a percentile and a target: p99 under 200 milliseconds means something and fast does not. Naming p99, the figure that 99 requests in every 100 come in under, also shows you know an average hides the users you are losing. Consistency, as what a user is allowed to see, so ask whether a follower must see a post immediately or whether a few seconds is fine. Availability, as nines plus a stated failure behaviour, because three nines is 8.7 hours down a year and somebody has to be comfortable with that.
The read-write ratio matters early, because it decides more than the other three combined. At 100 reads per write you can denormalise hard, cache almost everything and accept slow writes. At one to one none of that pays for itself. If you get a shrug, propose a ratio yourself and say what it implies.
Committing to a figure
Give them a number when they will not give you one. “You decide” is the test rather than an obstacle. Say that you will assume 10 million daily actives opening the app five times each, so around 600 requests per second and call it 2,000 at peak, and you have done three things at once. You made the problem concrete, you showed you can estimate, and you handed the interviewer something specific to push back on. Keep asking questions without ever committing and you look indecisive, which is the failure on the other side of drawing too early.
The numbers belong somewhere you can both see them. Every trade-off for the rest of the hour should point back at one of them, and “I am choosing this because we agreed p99 under 200 milliseconds” beats any component you can name.
Worked example
"It should be fast and handle a lot of users" is where the candidate starts. They turn it into four lines in about three minutes. Scale: 10M DAU, 5 sessions each, so 50M sessions a day, roughly 600 requests per second average, 2,000 at peak with a 3x factor. Latency: p99 under 200 ms for the feed read, and they say why p99 rather than mean. Consistency: a new post appearing within about 5 seconds is fine, so eventual, which immediately licenses caching and async fanout. Availability: three nines, and on failure the feed serves stale rather than erroring.
Thirty minutes later the interviewer asks whether to add a second cache layer. The candidate answers in one sentence: at 2,000 peak reads per second the existing cache already holds p99 at 40 ms, so a second layer buys nothing against a 200 ms budget and costs another failure mode. That answer is only available because the number existed. Without it the honest answer would have been a preference, and preferences do not survive follow-up questions.