Whether you’re designing a social media platform, payment system, or real-time collaboration tool, choosing the right API architecture can make or break your system’s performance and scalability. This post breaks down the most important API types you’ll need to know in system design interviews.
REST
REST (Representational State Transfer) is the most widely adopted API architecture style. It uses standard HTTP methods to perform operations on resources identified by URLs.
How it works:
Client sends HTTP request to a URL
Server processes request and returns data (usually JSON)
Each request is independent - server doesn’t remember previous requests
Key characteristics:
Stateless: Each request contains all information needed to process it
Resource-based: Everything is treated as a resource with a unique URI
Standard HTTP methods: GET (read), POST (create), PUT (update), DELETE (remove)
Multiple formats: Typically JSON, but can support XML, plain text, etc.
Example REST API methods
When to use: CRUD operations, public APIs, and when you need broad compatibility across different platforms and languages.
gRPC
gRPC is Google’s high-performance RPC framework that uses Protocol Buffers for serialization and HTTP/2 for transport.
How it works:
Define your API in a .proto file
gRPC generates code for client and server
Data transmitted as compressed binary
Supports streaming in both directions
Key characteristics:
Binary protocol: Uses Protocol Buffers instead of JSON
HTTP/2 based: Multiplexing, server push, header compression
Four communication patterns:
Unary (request-response)
Server streaming
Client streaming
Bidirectional streaming
Strongly typed: Contract-first development with .proto files
Example .proto definition
When to use: Building microservices, need high performance, or require real-time streaming.
GraphQL
GraphQL is a query language and runtime that allows clients to request exactly what data they need, solving the over-fetching and under-fetching problems of REST.
How it works:
Client sends a query specifying exact fields needed
Server returns only those fields
One endpoint handles all requests
Clients control the response shape
Key characteristics:
Single endpoint: All requests go to one URL
Flexible queries: Clients specify exact data requirements
Type system: Strongly typed schema
Real-time subscriptions: Built-in support for live updates
Self-documenting: Introspection capabilities
Example GraphQL query and response
When to use: Different clients need different data, you have complex relationships, or want to prevent over/under-fetching.
Webhooks
Webhooks implement an event-driven architecture where the server pushes data to clients when specific events occur, eliminating the need for constant polling. Instead of clients asking for updates, the server tells them when something happens.
How it works:
Client registers a URL with the server
When an event occurs, server sends HTTP POST to that URL
Client processes the event data
Key characteristics:
Push-based: Server initiates communication
Event-driven: Triggers on specific actions
HTTP POST: Typically sends JSON payload to registered URLs
Asynchronous: Fire-and-forget pattern
Simple example webhook flow
When to use: Payment notifications, CI/CD pipelines, third-party integrations, or any scenario where you need real-time event notifications.
WebSockets
WebSockets keep a connection open between client and server, allowing instant two-way communication.
How it works:
Client and server establish connection with special handshake
Connection stays open
Either side can send messages anytime
No request-response pattern needed
Key characteristics:
Persistent connection: Stays open after initial handshake
Low latency: No HTTP overhead for each message
Bidirectional: Both client and server can initiate messages
Text or binary: Supports multiple data formats
Example WebSocket setup
When to use: Chat applications, live sports scores, collaborative editing, real-time dashboards, or multiplayer games.
WebRTC
WebRTC enables peer-to-peer communication directly between browsers and applications without data passing through your servers.
How it works:
Browsers exchange connection info through your server
Once connected, they communicate directly peer-to-peer
Audio, video, and data flow directly between users
Your server doesn’t handle the media stream
Key characteristics:
Peer-to-peer: Direct connection between clients
Media streaming: Audio, video, and data channels
NAT traversal: Works across different networks using STUN/TURN
Encryption: Mandatory SRTP for media, DTLS for data
Example use case: In a video call application, after initial signaling through your server, participants exchange audio/video directly between their devices, reducing server load and latency.
When to use: Video conferencing, screen sharing, file sharing between users, or real-time collaboration tools.
Choosing the Right API
In system design interviews, selecting the appropriate API depends on several factors:
Latency requirements: gRPC or WebSockets for low latency
Data flexibility: GraphQL when clients need varied data shapes
Real-time needs: WebSockets for bidirectional, Webhooks for server-push
Bandwidth constraints: gRPC for efficient binary protocol
Peer-to-peer: WebRTC for direct client communication
Modern systems often combine multiple API types. A video conferencing system might use REST for user management, WebSockets for chat, WebRTC for video streams, and Webhooks for notifications.
Like posts like this?
By subscribing, you get a breakdown like this one every week.
Free subscribers also get a little bonus:
🎁 The System Design Interview Preparation Cheat Sheet
If you're into visuals, paid subscribers unlock:
→ My Excalidraw system design template – so you have somewhere to start → My Excalidraw component library – used in the diagram of this issue
No pressure though. Your support helps me keep writing, and I appreciate it more than you know ❤️
