REST vs GraphQL vs gRPC: Choosing an API (System Design)

Where the API step fits in a system design interview, how REST, GraphQL and RPC differ, and three questions that pick the right one, with a ticket-booking…

Choosing an API protocol: common questions

Should I use REST, GraphQL or gRPC in a system design interview?

Default to REST for anything browsers or phones call. Pick GraphQL when many clients need very different slices of the same data. Use gRPC between your own internal services. Add WebSockets or SSE only for live updates.

How long should the API part of a system design interview take?

About five minutes. Turn each requirement into one or two endpoints, show sensible names and where data goes, then move on to the high-level design.

Related chapters

Keep learning

Previous: API design in System Design
Next: API Goals Canvas: Design APIs from the Consumer
All System design chapters

Overview

RPC (gRPC) Only your own services call it. You control both sides, so you can use a fast binary format and a shared contract file. Browsers never see it. Many screens want very different slices of the same data. Letting each screen ask for exactly its fields saves extra round trips and wasted bytes. Browsers and phones call it, and the screens want roughly the same data. REST is what every developer already knows, works with every tool, and caches well. Lab: answer three questions, get a protocol 1. Who calls this API? Browsers, phone apps or other companies Only our own services, inside our servers 2. Do different screens need very different data? No, mostly the same fields Yes, each screen wants its own mix No, the client asks when it needs something Yes, the server must push + WebSockets or SSE for the live part Pick an answer for each question to see the result.

REST, GraphQL or RPC: picking the protocol

An API is the list of things a client is allowed to ask your system to do. This chapter shows where the API fits in the interview, the three common styles, and a three-question way to choose one.

What an API is

Think of a restaurant. You don’t walk into the kitchen. You read the menu, tell the waiter what you want, and food comes back. An API is that menu for software: a fixed list of requests a client may send, and what it gets back for each one. All through this section we use one example: a ticket booking site like Ticketmaster. People search for concerts, open an event page, pick seats and book. When the phone app opens the page for event 123, this happens: Phone app the client GET /events/123 the request: “give me event 123” looks it up in the database the response, as JSON A request goes out, a response comes back. The API decides which requests exist and what each returns.

Where the API fits in the interview

In a system design interview you first agree what the product must do (the requirements), then list the main things it stores (the entities: Event, Venue, Ticket, Booking). The API comes next, and it should take about five minutes. You turn each requirement into one or two requests: Each requirement becomes an endpoint (one request the API accepts) Users can search for events GET /events?query=coldplay Users can view an event GET /events/123 Users can see free seats GET /events/123/tickets Users can book seats POST /events/123/bookings The interviewer does not want every header and field. They want to see that the requests match the requirements, the names make sense, and you know where each piece of data goes. Save your time for the design that comes after.

Three styles of API

The menu can be written in three common styles. Each one solves a different problem, so it helps to know what each is good at. the default Every thing (an event, a booking) has its own address, like /events/123. You use a small set of verbs on it: GET to read, POST to create, DELETE to remove. client picks fields One single address. The client sends a little query that lists exactly which fields it wants, and gets back that shape and nothing more. Here is the same job, “get event 123 with its venue name”, in all three: REST: two requests GraphQL: one query, exact fields Notice the difference in thinking. REST talks about things (events, venues). GraphQL talks about the shape of data you want. RPC talks about actions (get, create). The next three chapters go through each one.

How to choose

Start with REST. It is the safe default for anything a browser or phone calls, and most interviewers expect it. Move away from it only when a question below gives you a reason. Try it: For our ticket site the answers are: browsers and phones call it, screens want similar data, and the seat map may change live. So: REST for the public API, maybe SSE for live seat updates, and gRPC between our own services behind the scenes.

Say it in the interview

“I’ll use REST for the public API since browsers and mobile apps call it and the data is resource-shaped. Internally services can talk over gRPC. If we need live seat updates I’d add SSE for that one screen.” That one sentence shows you know all three and chose on purpose. Next, before writing any URL: what the people calling the API need to get done. Spotify’s resource map GitHub’s GraphQL API shows what the other style costs to run. GitHub GraphQL limits

More courses

Jobs, linked to lessons — Browse jobs where every requirement links to the chapter that teaches it. See how ready you are, how long the gap takes to close, and which listings look stale.
Match a job post to courses — Paste a job post. Each skill is matched to a track here and put in learning order, foundations first.
React from open source with patterns — Patterns extracted from Material UI, Radix, React Aria, React Hook Form, Redux Toolkit, TanStack, and Next.js — not slides about hooks.
Database in depth — How a query becomes work. Indexes, isolation, locks, and the plans that explain why a page is slow — not an ORM tour.
Build a real API with NestJS — One ticket-booking API, built in order: a plain Node server first, then NestJS modules, validation, a real database, and the features real clients lean on.
Microservices — Microservice patterns one diagram at a time: how to split a monolith, how services talk, and how data stays consistent without distributed transactions.
Kafka — A beginner-to-senior path through event logs, reliable delivery, production operations, and disaster recovery.
AI engineering for software engineers — Eight free reads, in order, for software engineers moving into AI: when to build an agent, how to build one, how to test it, and how the model works underneath.
Frontend system design — How a UI is sliced when it is a product, not a page: ownership of state, cache, routes, and what happens when the network lies.
TypeScript in depth — The type system as a design tool. Inference, narrowing, generics, and the errors that mean the model is wrong — not a catalog of utility types.
CSS in depth — See the box, then the page. Visual chapters from the box model through Flexbox surprises, Grid, selectors, and units, then backgrounds, shapes, and visual effects, each with a playground.
Accessibility — Foundations first (WCAG in plain words, semantic HTML, lists, alt text), then hands-on HTML labs, a full pass of WAI-ARIA 1.3, and a final fix-the-page challenge.
Docker — What an image is, why layers cache, and how containers find each other on a network.
Redis — Fifteen Redis patterns, one picture each: cache, session, lock, counter, rate limiter, queue, and when Redis is the wrong tool.
Kubernetes — Kubernetes from zero to operators: why it exists, Pods, Deployments and Services, then configuration, networking, storage, scheduling, scaling and security.