API design basics

Early in a system design interview, after you have clarified requirements, you define the API: the exact set of requests a client is allowed to make and what each one does. It is the contract between the frontend (or another service) and your backend. Nail it down before you draw the architecture, because it forces you to state clearly what the system actually does.

You do not need to be an API expert. You need three things: a sensible way to name actions (REST), an understanding of why each request should stand on its own (statelessness), and the one idea that saves you from real bugs, making an operation safe to repeat (idempotency).

Get these and you can sketch a clean interface for any system, and answer the follow-up an interviewer loves: "what happens if the client retries?"