An API is the contract a service offers its callers: which operations exist, what each one takes and returns, how it fails, and how that set is allowed to change. It's the one part of a service outsiders can see, and the one part you cannot quietly change once clients have shipped against it. Everything behind it, the database, the services, the deploy schedule, you can rewrite this week. The contract, once a mobile app depends on it, belongs partly to somebody else.

In a system design interview, API design is usually a five-to-ten-minute step after the feature set is agreed. Start with a coherent endpoint set, including appropriate methods and status codes. Then be ready to explain the tradeoffs: why you chose that communication style instead of GraphQL, what happens when rows arrive while a client is paging, and how changes reach clients that have already shipped.

The examples use one concert-ticketing service and focus on the contract exposed to first-party public clients.