API Design for System Design Interviews
In almost every system design interview, you’re expected to define the APIs for the system you’re 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 of API design varies by interviewer. Some will be satisfied with a handful of endpoints and clean request/response shapes. Others will push further: idempotency, pagination, error models, auth, versioning, rate limits, and how your API holds up under real-world edge cases.
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.
In this chapter, we'll cover what you need to know about API design for interviews: REST fundamentals, GraphQL, RPC/gRPC, resource naming, request/response patterns, pagination and filtering, rate limiting, versioning, authentication, error handling, and practical examples that look like real production APIs.
Most of this chapter focuses on REST, since it’s the most common style in real-world systems and the default expectation in most system design interviews.