Answering at levels
How to say a design decision so it sounds reasoned: one design, the real alternatives, the axes that matter here, the choice, its cost, and the requirement that would change your mind.
Why does naming an alternative help, when I already know which design I want?
Because the interviewer cannot tell the difference between a design you chose and the first design you thought of. Both sound the same when you present only one. Naming a real alternative and saying why you are not taking it converts your answer from a recollection into a decision, and a decision is what a senior round is scoring. It also costs about twenty seconds, which is the cheapest score on the board.
How many alternatives should I bring up?
One or two. Three is already a survey, and a survey with no choice at the end reads as having no opinion. Pick the alternatives that a reasonable engineer would actually consider for this problem, not the exotic ones, and pick ones that differ on an axis the requirements care about. If two alternatives differ only on something the problem never mentions, you have spent the clock on nothing.
What exactly is the “flip condition” and why does it matter so much?
It is the one sentence that names the requirement change that would make you pick the other design: “if the read rate went up by an order of magnitude I would move the work to write time instead”. It matters because it is evidence that the choice came from the requirements rather than from memory. Anyone can recite that a document store scales writes; only somebody who reasoned about it can say which requirement was carrying the decision. That is why it is the cheapest part of the answer for an interviewer to test, and the part worth rehearsing.
Is CAP still worth talking about, or is it considered dated?
The theorem is narrow and it is still the right vocabulary for one specific question: when the network between two parts of a system breaks, do the affected operations keep answering with possibly stale data, or do they refuse? That question is real and it comes up in almost every distributed design. What is dated is treating CAP as a menu where you pick two of three, and lecturing on it. Name which side this scenario can afford to lose, say why, say what is given up, and move on.
The interviewer keeps asking “why not X?” after I have already chosen. What do they want?
Usually one of three things: they want to hear that you understand X properly, they are steering you because X is what they had in mind, or they are testing whether you defend a choice under pressure or abandon it. Handle all three the same way. Say what X buys, say the requirement that would make X the right answer, then say which requirement in this problem points the other way. If they push a second time on the same point, treat it as steering and switch, out loud, with the reason.