Most system design interviews eventually ask you to define the APIs for the system you are designing.

This is especially true for product-style questions (payments, ride hailing, e-commerce), where the API is the primary interface between clients, services, and users.

The depth varies by interviewer. Some will be satisfied with a handful of endpoints and clean request/response shapes. Stronger interviewers push further: idempotency, pagination, error models, auth, versioning, rate limits, and what happens when clients retry, upgrade slowly, or send expensive requests.

A good API shows you understand how clients will actually use the system, what data must flow between components, how to handle failures gracefully, and how to design for change without breaking existing users.

APIs are contracts. Once published, they're hard to change without breaking clients.

This chapter covers the API-design concepts these questions usually probe: REST fundamentals, GraphQL, RPC/gRPC, resource naming, request/response patterns, pagination and filtering, rate limiting, versioning, authentication, error handling, and practical examples.