Structure any system design answer

Spend the first five minutes on requirements

Ask about users, the read and write ratio, latency targets and what "done" looks like. Write the numbers down. You will use them to justify every choice later, and the questions themselves show the interviewer how you think.

Describe the simplest thing that works

Start with a client, an API and one data store. Walk a request through it from end to end before you add caches, queues or shards. A design that grows from a working baseline is easier to follow, and easier to defend, than one that starts with every component at once.

Then break it on purpose

Point at the component that fails first at ten times the load, propose a fix, and say what it costs you: complexity, money, consistency, latency. Naming trade-offs out loud is what separates mid-level answers from senior ones.

Go deep on one thing

Interviewers cannot assess a shallow tour of twelve boxes. Pick the part that matters most for this problem, such as the data model, the hot path or the failure handling, and go a level down. If they want a different area, they will redirect you.

Close the loop

Finish by restating what you built against the requirements you set at the start, and what you would do next with more time. It shows you can steer an open-ended problem to a conclusion.