REST vs RPC | Learn System Design

System Design

Learn System Design

Introduction to System Design

How to Learn System Design?

Key Characteristics of Distributed Systems

Scalability

Availability

Latency and Performance

Concurrency and Coordination

Monitoring and Observability

Resilience and Error Handling

Fault Tolerance vs. High Availability

Flashcards Review

Chapter Assessment

Network Essentials

HTTP vs. HTTPS

TCP vs. UDP

HTTP: 1.0 vs. 1.1 vs 2.0 vs. 3.0

URL vs. URI vs. URN

What Happens When You Type a URL into the Browser

Flashcards Review

Chapter Assessment

Long-Polling vs. WebSockets vs. Server-Sent Events

Introduction to Real-Time Communication

What is Long-Polling?

What is WebSocket?

What are Server-Sent Events?

Difference Between Long-Polling, WebSockets, and Server-Sent Events

Flashcards Review

Chapter Assessment

Domain Name System (DNS)

Introduction to DNS

DNS Resolution Process

DNS Load Balancing and High Availability

Flashcards Review

Chapter Assessment

Proxies

What is a Proxy Server?

Uses of Proxies

VPN vs. Proxy Server

Flashcards Review

Chapter Assessment

Load Balancing

Introduction to Load Balancing

Load Balancing Algorithms

Uses of Load Balancing

Load Balancer Types

Stateless vs. Stateful Load Balancing

High Availability and Fault Tolerance

Scalability and Performance

Challenges of Load Balancers

Flashcards Review

Chapter Assessment

API Gateway

Introduction to API Gateway

Usage of API gateway

Advantages and disadvantages of using API gateway

Flashcards Review

Chapter Assessment

API Design

What Is an API?

What Are REST APIs?

Resources, Not Actions

HTTP Methods and Their Semantics

URL Design

Request and Response Shapes

Status Codes and Error Design

Pagination from the Consumer's View

Idempotency Keys

Versioning and Backward Compatibility

Concurrency and Conditional Requests

REST vs gRPC vs GraphQL

Flashcards Review

Chapter Assessment

Rate Limiting and Throttling

What Is Rate Limiting

Rate Limiting Algorithms

Distributed Rate Limiting

Rate Limiting in Practice

Flashcards Review

Chapter Assessment

Caching

Introduction to Caching

Why is Caching Important?

Types of Caching

Cache Replacement Policies

Cache Invalidation

Cache Read Strategies

Cache Coherence and Consistency Models

Caching Challenges

Cache Performance Metrics

Flashcards Review

Chapter Assessment

CDN

What is CDN?

Origin Server vs. Edge Server

CDN Architecture

Push CDN vs. Pull CDN

Flashcards Review

Chapter Assessment

Data Partitioning

Introduction to Data Partitioning

Partitioning Methods

Data Sharding Techniques

Benefits of Data Partitioning

Common Problems Associated with Data Partitioning

Flashcards Review

Chapter Assessment

Redundancy and Replication

What is Redundancy?

What is Replication?

Replication Methods

Data Backup vs. Disaster Recovery

Flashcards Review

Chapter Assessment

CAP & PACELC Theorems

Introduction to CAP Theorem

Components of CAP Theorem

Trade-offs in CAP Theorem

Examples of CAP Theorem in Practice

Beyond CAP Theorem

System Design Trade-offs in Interviews

Flashcards Review

Chapter Assessment

Databases (SQL vs. NoSQL)

Introduction to Databases

SQL Databases

NoSQL Databases

SQL vs. NoSQL

ACID vs BASE Properties

Real-World Examples and Case Studies

SQL Normalization and Denormalization

In-Memory Database vs. On-Disk Database

Data Replication vs. Data Mirroring

Database Federation

Flashcards Review

Chapter Assessment

Indexes

What are Indexes?

How a B-Tree Index Works

Types of Indexes

B-Tree vs. LSM Tree

Indexes in Distributed Systems

Flashcards Review

Chapter Assessment

Bloom Filters

Introduction to Bloom Filters

Benefits & Limitations of Bloom Filters

Variants and Extensions of Bloom Filters

Applications of Bloom Filters

Flashcards Review

Chapter Assessment

Quorum

Why Quorum?

What is Quorum?

Flashcards Review

Chapter Assessment

Leader and Follower

What is Leader and Follower Pattern?

Flashcards Review

Chapter Assessment

Heartbeat

What is Heartbeat?

Flashcards Review

Chapter Assessment

Checksum

What is Checksum?

Uses of Checksum

Flashcards Review

Chapter Assessment

Distributed Messaging System

Introduction to Messaging System

Introduction to Kafka

Messaging patterns

Popular Messaging Queue Systems

RabbitMQ vs. Kafka vs. ActiveMQ

Scalability and Performance

Flashcards Review

Chapter Assessment

Distributed File Systems

What is a Distributed File System?

Architecture of a Distributed File System

Key Components of a DFS

Flashcards Review

Chapter Assessment

Security

What is Security and Privacy?

What is Authentication?

What is Authorization?

Authentication vs. Authorization

OAuth vs. JWT for Authentication

What is Encryption?

What are DDoS Attacks?

Flashcards Review

Chapter Assessment

Misc Concepts

Batch Processing vs. Stream Processing

XML vs. JSON

Synchronous vs. Asynchronous Communication

Push vs. Pull Notification Systems

Microservices vs. Serverless Architecture

Message Queues vs. Service Bus

Stateful vs. Stateless Architecture

Event-Driven vs. Polling Architecture

Flashcards Review

Chapter Assessment

Quiz - System Design Fundamentals

Quiz

System Design Trade-offs

Importance of Discussing Trade-offs

Strong vs Eventual Consistency

Latency vs Throughput

ACID vs BASE Properties in Databases

Read-Through vs Write-Through Cache

Batch Processing vs Stream Processing

Load Balancer vs. API Gateway

API Gateway vs Direct Service Exposure

Proxy vs. Reverse Proxy

API Gateway vs. Reverse Proxy

SQL vs. NoSQL

Primary-Replica vs Peer-to-Peer Replication

Data Compression vs Data Deduplication

Server-Side Caching vs Client-Side Caching

REST vs RPC

Polling vs. Long-Polling vs. WebSockets vs. Webhooks

CDN Usage vs Direct Server Serving

Serverless Architecture vs Traditional Server-based

Stateful vs Stateless Architecture

Hybrid Cloud Storage vs All-Cloud Storage

Token Bucket vs Leaky Bucket

Read Heavy vs Write Heavy System

Quiz

How to Approach a System Design Interview

System Design Interviews - A step by step guide

Functional vs. Non-functional Requirements

What are Back-of-the-Envelope Estimations?

Things to Avoid During System Design Interview

System Design Master Template

Quiz

Designing a URL Shortening Service like TinyURL

Quiz - Designing URL Shortner

Designing Pastebin

Quiz - Designing Pastebin

Designing Instagram

Quiz - Designing Instagram

Designing Dropbox

Quiz - Designing Dropbox

Designing Facebook Messenger

Quiz - Designing Facebook Messenger

Designing Twitter

Quiz - Designing Twitter

Designing Youtube or Netflix

Quiz - Designing Youtube

Designing Typeahead Suggestion

Quiz - Designing Typeahead Suggestion

Designing an API Rate Limiter

Quiz - Designing an API Rate Limiter

Designing Twitter Search

Quiz - Designing Twitter Search

Designing a Web Crawler

Quiz - Designing a Web Crawler

Designing Facebook’s Newsfeed

Quiz - Designing Facebook’s Newsfeed

Designing Yelp or Nearby Friends

Quiz - Designing Yelp or Nearby Friends

Designing Uber backend

Quiz - Designing Uber backend

Designing Ticketmaster

Quiz - Designing Ticketmaster

Dynamo: How to design a key value store?

Dynamo: Introduction

High-Level Architecture

Data Partitioning

Replication

Vector Clocks and Conflicting Data

The Life of Dynamo’s put() & get() Operations

Anti-entropy Through Merkle Trees

Gossip Protocol

Dynamo Characteristics and Criticism

Summary: Dynamo

Quiz: Dynamo

Mock Interview: Dynamo

Designing YouTube Likes Counter (medium)

YouTube Likes Counter

Quiz

Cassandra: How to Design a Wide-column NoSQL Database?

Cassandra: Introduction

High-level Architecture

Replication

Cassandra Consistency Levels

Gossiper

Anatomy of Cassandra's Write Operation

Anatomy of Cassandra's Read Operation

Compaction

Tombstones

Summary: Cassandra

Quiz: Cassandra

Mock Interview: Cassandra

Kafka: How to Design a Distributed Messaging System?

Messaging Systems: Introduction

Kafka: Introduction

High-level Architecture

Kafka: Deep Dive

Consumer Groups

Kafka Workflow

Role of ZooKeeper

Controller Broker

Kafka Delivery Semantics

Kafka Characteristics

Summary: Kafka

Quiz: Kafka

Mock Interview: Kafka

Chubby: How to Design a Distributed Locking Service?

Chubby: Introduction

High-level Architecture

Design Rationale

How Chubby Works

File, Directories, and Handles

Locks, Sequencers, and Lock-delays

Sessions and Events

Master Election and Chubby Events

Caching

Database

Scaling Chubby

Summary: Chubby

Quiz: Chubby

Mock Interview: Chubby

HDFS: How to Design File Storage System?

Hadoop Distributed File System: Introduction

High-level Architecture

Deep Dive

Anatomy of a Read Operation

Anatomy of a Write Operation

Data Integrity & Caching

Fault Tolerance

HDFS High Availability (HA)

HDFS Characteristics

Summary: HDFS

Quiz: HDFS

Mock Interview: HDFS

GFS: How to Design a Distributed File System Storage?

Google File System: Introduction

High-level Architecture

Single Master and Large Chunk Size

Metadata

Master Operations

Anatomy of a Read Operation

Anatomy of a Write Operation

Anatomy of an Append Operation

GFS Consistency Model and Snapshotting

Fault Tolerance, High Availability, and Data Integrity

Garbage Collection

Criticism on GFS

Summary: GFS

Quiz: GFS

Mock Interview: GFS

BigTable: How to Design a Wide Column Storage System?

BigTable: Introduction

BigTable Data Model

System APIs

Partitioning and High-level Architecture

SSTable

GFS and Chubby

Bigtable Components

Working with Tablets

The Life of BigTable's Read & Write Operations

Fault Tolerance and Compaction

BigTable Refinements

BigTable Characteristics

Summary: BigTable

Quiz: BigTable

Mock Interview: BigTable

Designing Reddit (medium)

Design Reddit

Quiz

Designing Notification Service (medium)

Designing a Notification System

Quiz

Design Google Calendar (medium)

Design Google calendar (Medium)

Quiz

Design a Recommendation System (medium)

Design a Recommendation System for Netflix

Quiz

Designing Gmail (medium)

Design Gmail

Quiz

Designing Google News (medium)

Design Google News, a Global News Aggregator System (Medium)

Quiz

Designing Unique ID Generator (medium)

Design Unique ID Generator (Easy)

Quiz

Designing Code Judging System (medium)

Design Code Judging System like LeetCode (Medium)

Quiz

Designing Payment System (hard)

Design Payment System

Quiz

Designing Flash Sale System (hard)

Design a Flash Sale for an E-commerce Site (Hard)

Quiz

Designing Reminder Alert System (hard)

Design a Reminder Alert System

Quiz

System Design Patterns

Introduction: System Design Patterns

1. Bloom Filters

2. Consistent Hashing

3. Quorum

4. Leader and Follower

5. Write-ahead Log

6. Segmented Log

7. High-Water Mark

8. Lease

9. Heartbeat

10. Gossip Protocol

11. Phi Accrual Failure Detection

12. Split Brain

13. Fencing

14. Checksum

15. Vector Clocks

16. CAP Theorem

17. PACELC Theorem

18. Hinted Handoff

19. Read Repair

20. Merkle Trees

Quiz

REST vs RPC

api design

distributed systems

rest

asynchronous communication

hard

8 min

·Updated Aug 2026·Credit: Grokking the System Design Interview

You are splitting one application into services. The order service must now call the catalog service across the network. Every call needs a shape. Should the API name things, or should it name actions?

That is the REST against RPC decision. In REST, you name things. GET /articles/42 asks for one article, and the HTTP method says what to do with it. In RPC, you name actions. getArticle(42) calls a function that runs on another machine.

This naming difference decides everything else about the two styles. It is not a difference of data formats, and this lesson will clear that confusion up.

REST names a resource with a URL, while RPC names an action by calling a remote function

REST

REST treats your system as a collection of resources. A resource is a thing with its own URL. The standard HTTP methods act on it.

GET    /articles        list the articles
POST   /articles        create a new one
GET    /articles/42     read one
PUT    /articles/42     replace it
DELETE /articles/42     delete it

What it gives you.

A uniform interface. Every resource is used through the same few methods. Any developer with any HTTP client can call your API.
Statelessness. Each request carries everything the server needs. The server keeps nothing between calls, so any server can answer any request. Stateful vs Stateless Architecture explains why that helps scaling.
Caching by the infrastructure you already have. A GET is safe to repeat, and every cache on the path knows it. Browsers, CDNs, and proxies can store the response without understanding your application. Caching covers those layers.
Easy debugging. Responses are readable text. You can test any endpoint with a browser or curl.

What it costs you.

Over-fetching and under-fetching. An endpoint returns one fixed shape. Over-fetching means the client downloads fields it will not use. Under-fetching means one screen needs data from several resources, so it makes several round trips.
Awkward actions. "Send this invoice for approval" is an action, not a thing. Forcing it into a resource produces strange URLs such as POST /invoices/42/approval-requests.
No enforced contract. REST is a set of conventions. Nothing checks that the client and the server agree. A breaking change is discovered at runtime, by a failing client.

RPC and gRPC

RPC stands for Remote Procedure Call. The client calls what looks like a normal function. A framework packs the arguments, sends them over the network, and returns the result.

In modern systems, RPC usually means gRPC, an open source RPC framework. Three features define it.

A written contract. You describe every method, argument, and return type in a .proto file.
Code generation. Tools generate the client and the server code from that file. Rename a field, and the build fails. The mistake is caught at compile time, not by a user in production.
A fast wire format. Messages are encoded as Protocol Buffers, a compact binary format. They travel over HTTP/2, which can carry many calls on one connection at the same time. gRPC also supports streaming, where a single call carries a whole sequence of messages, in either direction.

One .proto contract file generates matching client and server code, so a renamed field fails the build instead of failing users

What it gives you.

Speed. Binary messages are smaller than JSON and cheaper to parse. Shared connections remove repeated setup work. This matters most when one user request fans out into many internal calls.
Safety. The generated contract removes a whole class of integration bugs.
Streaming. A server can send a stream of results over one call.
Natural actions. You were going to call a function anyway.

What it costs you.

It requires HTTP/2, and browsers cannot call it directly. A browser cannot make a raw gRPC call. You need a translation layer such as gRPC-Web, or a REST API in front.
Not readable. A binary payload cannot be inspected by eye. Debugging needs tooling.
No HTTP caching. To the infrastructure in between, every call looks like a POST. Proxies and CDNs cannot cache it.
Tighter coupling. Both sides build from the same contract. A change needs coordination between the teams.

The Difference Is Not the Data Format

A common shortcut says REST is "the JSON one" and gRPC is "the binary one". The shortcut is wrong.

A REST API can return JSON, XML, HTML, or an image. Content negotiation is the HTTP feature that lets a client ask for the format it prefers. Many long-running REST APIs serve XML to this day. And RPC is not always binary, because JSON-RPC sends plain JSON text.

Most REST APIs do choose JSON, and gRPC does use Protocol Buffers. But that is a consequence of each style, not the line between them. The line is what you name, and what is enforced. REST names resources and relies on convention. gRPC names procedures and enforces a compiled contract.

A REST GET can be answered by a CDN cache on the path, while every gRPC call looks like a POST and reaches the server

Where Each One Usually Lives

The two styles are not competitors inside one system. Most large systems run both, in different places.

REST sits at the edge. The callers there are browsers, mobile apps, and third-party developers. You do not control them, so the universal, cacheable option wins. An API gateway usually receives this traffic.

gRPC runs inside. Between your own services, you control both ends. One user request may fan out into ten internal calls, so the speed matters. The enforced contract also prevents integration mistakes between teams.

Browsers, mobile apps, and partners call a REST API gateway, while the services inside call each other with gRPC over HTTP/2

One more style deserves a sentence, because interviewers mention it. GraphQL is a query language where the client lists exactly the fields it wants. It exists to fix over-fetching and under-fetching. Its costs are losing default HTTP caching and having to protect the server from expensive queries.

Comparison

	REST	gRPC
You name	Resources (things)	Procedures (actions)
Transport	HTTP/1.1 or HTTP/2	HTTP/2 only
Payload	Any format, usually JSON	Protocol Buffers (binary)
Contract	Convention, optionally OpenAPI	Enforced by code generation
HTTP caching	Works	Not available
Streaming	Limited	Built in, both directions
Browser support	Native	Needs a proxy layer
Best place	The public edge	Service to service, inside

Choosing

Public API, third-party callers, browsers: REST. You do not control the callers, so ubiquity and caching win.
Internal service-to-service calls at high volume: gRPC. You control both ends, and the speed and the contract matter there.
Streaming between services: gRPC, because streaming is built in.
A mobile screen that needs many resources at once: consider GraphQL, or one endpoint shaped for that screen.
Both needs in one system: use both. gRPC inside, REST at the edge. This is the normal answer, not a compromise.

💡 In the interview: the expected shape is REST at the edge and gRPC inside, and what earns credit is the reason. Say: "gRPC between services, because one request fans out to eight internal calls, and binary messages over shared HTTP/2 connections cut that latency. REST at the edge, because browsers and partners cannot speak gRPC." Expect the follow-up "why not gRPC everywhere?" Answer that browsers need a proxy layer for it, and that you lose HTTP caching. And if REST is described as "the JSON one", correct it: REST can serve XML too, and the real difference is resources against procedures.

Key takeaway: REST names resources, acts on them with HTTP methods, and relies on convention. It gives you universal clients, statelessness, and caching by the existing HTTP infrastructure. gRPC names procedures, enforces a compiled contract through code generation, and sends binary messages over HTTP/2 with streaming built in. It is faster and safer for internal calls, but it needs HTTP/2, cannot use HTTP caching, and browsers cannot call it directly. The data format is not the difference. Choose REST for the public edge, gRPC for service-to-service traffic, and expect real systems to use both.

Discussion

Have a question or insight about this topic? Share it with the community.

Reading Progress

On This Page