---

?? 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.