System Design Protocols: REST, RPC, and TCP/UDP

Scenario context

🎯 Use REST (HTTP + JSON) for public, browser-facing APIs where interoperability matters. Choose gRPC (HTTP/2 + Protobuf) for internal microservice communication when latency counts. Under the hood, TCP guarantees reliable ordered delivery; UDP trades reliability for speed. Know which layer you're operating at and pick the right tool for each job.

gRPC — Google's Remote Procedure Call framework — transfers the…

This walkthrough focuses on The Protocol Stack: What Talks to What.

Before making a design choice, clarify:

• gRPC — Google's Remote Procedure Call framework — transfers the same payload as REST in 60–80% fewer bytes by using binary Protobuf encoding instead of verbose JSON text.
• For a service handling one million RPCs per second, that compression gap is roughly the difference between $12,000 and $20,000 per month in bandwidth costs.
• Protocol choice is a real engineering and business decision, not a stylistic preference.

Concepts in play: api-gateway, system-design-hld-architectures, load-balancing, stack-and-queue-data-structures

Stage 1 — How REST Actually Works: Request → Response

• A REST API treats everything as a resource identified by a URL.
• You act on resources using HTTP verbs.
• A GET on /users/42 fetches that user; a POST to /users creates a new one; PUT replaces the entire resource at a given URL; PATCH applies a partial update; and DELETE removes it.
• The HTTP response includes a status code (200 OK, 404 Not Found, 500 Internal Server Error) and usually a JSON body.

sequenceDiagram
    participant C as Client
    participant LB as Load Balancer
    participant API as API Server
    participant DB as Database

    C->>LB: GET /users/42 (HTTPS)
    LB->>API: Route to available server
    API->>DB: SELECT * WHERE id=42
    DB-->>API: User row
    API-->>LB: 200 OK {id:42, name:"Alice"}
    LB-->>C: 200 OK {id:42, name:"Alice"}
    Note over C,LB: GET is cacheable (Cache-Control)

    C->>LB: POST /users {name:"Bob"}
    LB->>API: Route to server
    API->>DB: INSERT INTO users ...
    DB-->>API: New id=43
    API-->>LB: 201 Created Location:/users/43
    LB-->>C: 201 Created Location:/users/43

Observable outcome: The HTTP response includes a status code (200 OK, 404 Not Found, 500 Internal Server Error) and usually a JSON body.

Stage 2 — Deep Dive: How Protobuf Binary Encoding Works

• Protobuf serializes each field as a compact (field number, wire type) tag followed by the value.
• Field names are never sent over the wire — only numeric tags defined in the .proto file.
• A string "hello" in JSON is 7 bytes; in Protobuf it is 5 bytes plus a 1-byte tag.
• For messages sent millions of times per day, this 3–10× size reduction translates directly into bandwidth savings and lower serialization latency.

Observable outcome: For messages sent millions of times per day, this 3–10× size reduction translates directly into bandwidth savings and lower serialization latency.

Stage 3 — How gRPC Works: Contracts and Binary Efficiency

• gRPC starts with a Protobuf schema ( .proto file) that defines services and message types.
• A service definition declares each RPC method by name, specifying its request type and return type — for example, a GetUser unary call that takes a user ID and returns a User message, or a ListUsers server-streaming cal…
• Message types declare each field with a name, a scalar type (int32, string, bool, etc.), and a unique field number.
• That field number — not the name — is what travels over the wire.

Observable outcome: That field number — not the name — is what travels over the wire.

Stage 4 — WebSockets: Persistent Bidirectional TCP

• REST is request-response: the client asks, the server answers.
• But what if the server needs to push data to the client without being asked?
• WebSockets upgrade an HTTP connection to a persistent, full-duplex channel.
• Once the handshake completes, both sides can send messages independently at any time.

sequenceDiagram
    Client->>Server: HTTP Upgrade: websocket
    Server-->>Client: 101 Switching Protocols
    Server-->>Client: {"event": "price_update", "value": 142.50}
    Client->>Server: {"action": "subscribe", "symbol": "AAPL"}
    Server-->>Client: {"event": "price_update", "value": 143.10}

Observable outcome: Once the handshake completes, both sides can send messages independently at any time.

Stage 5 — Protocol Decision Flow

• Use this flowchart to select the right protocol for each service boundary in your system.
• Choose the outermost layer first: if external clients or browsers need access, REST is the safest default.
• For internal high-throughput paths, gRPC's binary encoding reduces payload size by 3–10× compared to JSON.

flowchart TD
    A[New Service Interface] --> B{External or public-facing?}
    B -->|Yes| C[REST + JSON over HTTPS]
    B -->|No| D{Need real-time streaming?}
    D -->|Server push to browser| E[WebSocket]
    D -->|Internal bidirectional| F[gRPC bidirectional streaming]
    D -->|No streaming needed| G{Latency and throughput critical?}
    G -->|Yes| H[gRPC + Protobuf over HTTP/2]
    G -->|No| C

Observable outcome: For internal high-throughput paths, gRPC's binary encoding reduces payload size by 3–10× compared to JSON.

Stage 6 — Practical Protocol Selection Checklist

• This checklist translates the REST-vs-gRPC-vs-UDP decision framework from the protocol sections into a concrete set of diagnostic questions you answer for each service boundary in your system.
• It was structured as a per-protocol checklist because the most common mistake is picking a single protocol for an entire application — in practice, a well-designed system uses different protocols at different layers.
• As you work through each section, answer honestly: if your answers for the gRPC block are all "yes," that boundary is a genuine gRPC candidate; if even one answer is "no," the tooling overhead may not be justified by th…
• For REST: - Is the API public or consumed by third-party developers?

Observable outcome: For REST: - Is the API public or consumed by third-party developers?

End-to-end outcome

gRPC — Google's Remote Procedure Call framework — transfers the same payload as REST in 60–80% fewer bytes by using binary Protobuf encoding instead of verbose JSON text.

Alternatives considered

REST vs. gRPC: The API Protocol Showdown

These are the two dominant choices for service-to-service communication.

TCP vs. UDP: The Transport Layer Choice

REST and gRPC both run over TCP .

Decision Guide: Protocol Selection by Use Case

Decision Guide: Protocol Selection by Use Case

Failure and degraded modes

Trade-offs & Failure Modes: Protocol Trade-offs

• Detection: simplicity: JSON is easy to debug with curl or browser DevTools, but verbose at scale — large payloads raise bandwidth costs and serialization latency on hot paths.
• User or operator impact: simplicity: JSON is easy to debug with curl or browser DevTools, but verbose at scale — large payloads raise bandwidth costs and serialization latency on hot paths.