Dropping JSON for Protobufs in Internal Microservices

JSON is Too Expensive

Why internal services should stop shouting and start whispering.

The 'Bubble Wrap' Analogy

• JSON Payload — Sending a smartphone wrapped in 50 layers of bubble wrap.
• The Waste — You pay to transmit field names ("userName": "...") over and over again.
• The Cost — In a high-throughput system, this text parsing burns 30-50% of CPU.

Computers Don't Need English

• Human Readable — JSON is great for public APIs because humans can read it in the browser.
• Machine Efficient — Service A talking to Service B doesn't need readability. It needs speed.

Enter Protocol Buffers (Protobuf)

[Image of Protobuf binary serialization diagram] Schema-driven binary serialization.

• The Schema — You define the data structure upfront in a .proto file.
• The Payload — It sends binary data. No field names, just values mapped to positions.
• Size — Payloads are typically 5x smaller than equivalent JSON.

gRPC vs REST

• Transport — REST usually runs on HTTP/1.1 (Text). gRPC runs on HTTP/2 (Binary Multiplexing).
• Typing — gRPC generates strong types for Java, Go, TS automatically. No more any.

The Schema Contract

• Backward Compatibility — Protobuf handles field numbering (tag = 1). You can add fields without breaking old clients.
• Code Gen — The .proto file is the single source of truth. Client SDKs are auto-generated.

When to stick with JSON?

• Public APIs — External developers hate binary formats. Keep your public face RESTful.
• Simple Debugging — If you need to curl the endpoint manually often.

Summary: Silence is Golden

Stop paying the JSON tax.

For internal chatter, binary beats text every time.

Are your internal services still speaking JSON?