- Published on
REST vs gRPC - System Design Interview Guide
Table of Contents
- ?? 1. Core Idea (1-line difference)
- ?? 2. REST (High Signal)
- ? What it does
- ?? Key Insight
- ??? Architecture Signals (Use REST when)
- ? Problems
- ?? FAANG Q&A
- ?? Script
- ?? 3. RPC (High Signal)
- ? What it does
- ?? Key Insight
- ??? Architecture Signals (Use RPC when)
- ? Problems
- ?? FAANG Q&A
- ?? Script
- ?? 4. Key Differences (Interview Table)
- ?? Script
- ?? 5. Real Architecture (FAANG Level)
- ? Use BOTH (Very Important)
- ?? Why?
- ?? FAANG Q&A
- ?? Script
- ?? 6. Strong Signals vs Weak Signals
- ?? Choose REST (Strong Signals)
- ?? Choose RPC (Strong Signals)
- ?? Weak Signals
- ?? 7. FAANG-Level Insights (Added)
- ?? 1. GraphQL vs REST
- ?? 2. gRPC Features
- ?? 3. API Gateway Role
- ?? 4. Versioning
- ?? Final Ultra-Short Summary
?? 1. Core Idea (1-line difference)
- REST ? Resource-based (data-oriented, HTTP standard)
- RPC ? Action-based (function call over network)
?? Script
�REST exposes resources via HTTP, while RPC exposes actions as remote function calls.�
?? 2. REST (High Signal)
? What it does
-
Uses HTTP methods:
- GET, POST, PUT, DELETE
-
Works with resources (URLs)
-
Stateless (each request independent)
-
Data format: JSON / XML
?? Key Insight
?? Prioritizes scalability + simplicity + standardization
??? Architecture Signals (Use REST when)
- Public APIs (web/mobile clients)
- Need caching (HTTP cache, CDN)
- Loose coupling between client & server
- CRUD-based systems
? Problems
- Over-fetching / under-fetching
- Multiple requests needed
- Less efficient for internal communication
?? FAANG Q&A
Q1: Why REST scales well? ?? Stateless + cacheable.
Q2: Problem with REST in microservices? ?? Too many network calls (chatty APIs).
Q3: How to fix over-fetching? ?? GraphQL (alternative).
?? Script
�I use REST for public APIs because it is stateless, scalable, and leverages HTTP caching.�
?? 3. RPC (High Signal)
? What it does
-
Calls functions remotely
-
Example:
getUser(id) -
Formats:
- JSON-RPC
- gRPC (Protocol Buffers - binary)
?? Key Insight
?? Prioritizes performance + efficiency
??? Architecture Signals (Use RPC when)
- Internal microservices communication
- Need low latency
- High throughput systems
- Strong contract between services
? Problems
- Tight coupling
- Less flexible
- Harder to evolve APIs
?? FAANG Q&A
Q1: Why gRPC faster than REST? ?? Binary format + smaller payload + HTTP/2.
Q2: Why not use RPC for public APIs? ?? Hard to use, less flexible, not browser-friendly.
Q3: Tradeoff? ?? Performance vs flexibility.
?? Script
�I use RPC for internal services where performance and low latency are critical.�
?? 4. Key Differences (Interview Table)
| Aspect | REST | RPC |
|---|---|---|
| Style | Resource-based | Action-based |
| Interface | HTTP standard | Custom methods |
| Coupling | Loose | Tight |
| Performance | Moderate | High |
| Caching | ? Built-in | ? Limited |
| Use Case | Public APIs | Internal services |
?? Script
�REST is flexible and scalable, while RPC is efficient and performance-oriented.�
?? 5. Real Architecture (FAANG Level)
? Use BOTH (Very Important)
Client ? REST API Gateway
?
Internal Services ? RPC (gRPC)
?? Why?
- REST ? easy for clients (browser/mobile)
- RPC ? fast for backend communication
?? FAANG Q&A
Q: Why not REST everywhere? ?? Too slow for internal high-frequency calls.
Q: Why not RPC everywhere? ?? Not user-friendly, lacks caching, tight coupling.
?? Script
�In production, I use REST externally and RPC internally to balance usability and performance.�
?? 6. Strong Signals vs Weak Signals
?? Choose REST (Strong Signals)
- �Public API�
- �Browser/mobile clients�
- �Caching required�
- �Loose coupling�
?? Choose RPC (Strong Signals)
- �Microservices communication�
- �Low latency critical�
- �High throughput�
- �Internal system�
?? Weak Signals
- �Microservices ? always REST� ?
- �Performance ? always RPC� ?
?? 7. FAANG-Level Insights (Added)
?? 1. GraphQL vs REST
- Solves over-fetching problem
?? 2. gRPC Features
- HTTP/2 multiplexing
- Streaming support
- Strong schema (Protobuf)
?? 3. API Gateway Role
- Converts REST ? RPC internally
?? 4. Versioning
- REST ? URL versioning (
/v1/users) - RPC ? schema evolution
?? Final Ultra-Short Summary
?? Golden Line
�REST is for external simplicity. RPC is for internal performance.�
If you want next, I can turn ALL these topics into a single �FAANG System Design Master Script� that you can literally memorize for interviews.