Why API Design Matters

The contract between systems

An API is the contract that lets clients talk to your service without knowing how it is built internally. In system design interviews, the API layer is where you make your first big architectural choice: how requests are shaped, encoded, and routed. Get this wrong and you pay for it everywhere — in latency, in client complexity, and in how painful future changes become.

Three styles dominate modern systems, each born from a different pressure:

• REST — resource-oriented HTTP. Ubiquitous, cacheable, browser-friendly. The default for public APIs.
• gRPC — a binary contract over HTTP/2 with Protobuf. Low latency, strongly typed, streaming. The default for internal service-to-service traffic.
• GraphQL — a single endpoint where the client specifies exactly what it wants. Solves over- and under-fetching for rich, varied UIs.

None is universally best. The interview signal is whether you can match the style to the workload: who the caller is, how the data is shaped, how chatty the client is, and how much latency budget you have.