Key Question

How do RPC frameworks ensure both sides agree on the message format?

Deep Dive

Without a shared contract, the client could send {"name": "Alice"} while the server expects bytes encoding [0x01, 0x00, 0x00, 0x00, 0x41, 0x6c, 0x69, 0x63, 0x65]. The Interface Definition Language (IDL) is the contract that prevents this mismatch.

Interface Definition Language (IDL)

An IDL is a language-neutral schema that defines the types and methods both sides agree on. Example in Protocol Buffers (protobuf):

syntax = "proto3";

message Person {
  string name = 1;
  int32 id = 2;
  string email = 3;
}

The IDL compiler generates:

• Client stub (for the caller)
• Server stub/skeleton (for the callee)
• Serialization/deserialization code in multiple languages

A single .proto file can generate Java, Go, Python, and C++ code. Both sides compile from the same IDL — they must agree, or the call fails.

Serialization Formats Compared

Serialization converts in-memory data structures into a format suitable for network transmission.

Raw data:  Person{name: "Alice", id: 42, email: "a@b.com"}
─────────────────────────────────────────────────────────────

JSON:      {"name":"Alice","id":42,"email":"a@b.com"}
           Size: ~45 bytes | Speed: slow (text parsing)

Protobuf:  0A05416C69636510D4021A076140622E636F6D
           Size: ~16 bytes | Speed: fast (binary, no parsing)

Thrift:    Similar size/speed to Protobuf (TCompactProtocol)
           ~17 bytes      | Schema required

Avro:      0x0A 0x05 0x41 0x6C 0x69 0x63 0x65 ... 
           Size: ~15 bytes | Schema sent with data (evolution-friendly)

Key Trade-offs

• JSON is unbeatable for debugging and simple APIs. But parsing JSON is CPU-intensive and the wire size is 2-3x binary formats.
• Protobuf uses field numbers (not names) on the wire, which makes messages small and schema evolution safe. Adding a new field doesn’t break old clients — they ignore unknown fields.
• Avro is special: the schema is embedded or known at read time. This makes Avro the best choice for data pipelines where the writer and reader may have different schema versions (e.g., Kafka, Hadoop).

Check Your Understanding

1. A protobuf message has fields: string name = 1; int32 age = 2;. A client sends bytes for a message with int32 id = 2; float salary = 3;. What happens on the server side?

2. Why is JSON slower than Protobuf for large messages?

3. When would you choose Avro over Protobuf?

The “So What?”

Serialization is the single biggest performance lever in most RPC systems. Switching from JSON to Protobuf can cut latency by 5-10x (less data on the wire, less CPU deserializing). The IDL is also your living API documentation — if you can read the .proto file, you understand the contract. In production systems, never let clients and servers serialize independently without a shared schema; you will get mysterious parse errors at 3 AM.

✏️ Exercises

Exercises: Architectural Models & RPC

Exercise 1: Architecture Choice

A team is building a file-sharing application for 100,000 users. Files are read-heavy (mostly downloads), users are geographically distributed, and there is no budget for centralized infrastructure.

1. Which architectural model (client-server, P2P, multi-tier, hybrid) would you recommend?
2. What specific design decisions would you make to handle the read-heavy workload?
3. What are the top three problems you’d need to solve?

Exercise 2: RPC Call Failure Analysis

A client calls deductBalance(userID: "u42", amount: 50.00) via RPC. The client stub sends the request to the server. For each scenario below, state what happens and whether the client’s balance is correct:

1. The client stub marshals the request and sends it. The server receives it, unmarshals, calls the function (which deducts $50 from the DB), but the server crashes before sending the response.
2. The server receives the request, processes it, and sends the response. The response is lost in the network. The client times out and throws an exception.
3. The client sends the request. The server processes it and sends the response. The client receives the response. Everything works — but the network duplicates the request and the server processes it twice.

Exercise 3: Protobuf Field Evolution

You have this protobuf schema deployed in production:

message Order {
  string order_id = 1;
  string user_id = 2;
  float total = 3;
}

You want to add a string coupon_code = 4 field. Some old server instances still running don’t know about field 4.

1. Will old servers crash when they receive a message with coupon_code set?
2. A client built from the old schema processes a message that has coupon_code. What does the client see?
3. What happens if you later delete field 3 (total) and reuse its number for a new int64 total_cents = 3?