Data Serialization Formats

What is it?

📦 Think of it like packing for a move:

When you move houses, you can't just teleport your furniture. You need to PACK it into boxes, label them, transport them, and UNPACK at the new house.

Serialization is the same thing for data. When your app wants to send data (like a user profile) across the internet, it can't send a live JavaScript object through a wire. It must PACK the data into a format (like JSON or Protobuf), send those bytes, and the receiving end UNPACKS it back into usable data.

Different formats are like different box sizes:

💡 Simple Summary: Serialization = converting data into a format that can be stored or sent over a network. JSON (human-readable, flexible) vs Protobuf (binary, fast, compact).

How it works — Like you're watching it happen

When Instagram app fetches your profile:

With Protobuf (binary):

❓ But wait — if Protobuf is faster and smaller, why doesn't everyone use it?

JSON is UNIVERSALLY readable. Open a JSON file — you can read it instantly. Open a Protobuf file — binary gibberish. For public APIs (consumed by millions of developers), JSON wins because anyone can use it without installing special tools. For INTERNAL service-to-service communication (where speed matters and both sides control the code), Protobuf wins because performance > readability.

Why should you care? (Interview perspective)

Key Things to Remember

Real Examples You Use Daily

🌐 Every website/API — When your browser calls an API, the response is almost always JSON: {"posts": [{"id": 1, "text": "hello"}, ...]}. Human-readable, easy to debug in browser DevTools.

🚗 Uber internal — Between their 2000 microservices, Uber uses Protobuf/gRPC. Rider Service → Pricing Service → Matching Service all communicate in compact binary. At their scale, JSON would waste terabytes of bandwidth daily.

📊 Kafka data pipelines — When companies stream millions of events through Kafka (user clicks, purchases, logs), they often use Avro format. Schema registry ensures everyone producing/consuming data agrees on the format, even as it evolves.

📱 Mobile apps — Apps like Instagram send/receive JSON from APIs. But internally, Instagram stores some data in compact binary formats in the database for efficiency. The translation (serialization/deserialization) happens at the API layer.

Common Mistakes in Interviews

❌ Always defaulting to JSON — For a public API? Yes, JSON. But for internal service communication at high scale? Protobuf can be 5-10x more efficient. Show you know alternatives.

❌ Ignoring schema evolution — "We'll use Protobuf." How do you add a new field without breaking old services? Discuss backward/forward compatibility (optional fields, field numbers).

❌ Forgetting compression — Even with JSON, gzip compression reduces size by 80-90%. Always mention compression for HTTP responses.

❌ Not considering parse time — At high QPS (100K+ requests/sec), JSON parsing becomes a significant CPU cost. Protobuf parsing is 10-100x faster. This matters for hot paths.

❌ Ignoring the debugging trade-off — Protobuf is faster but you can't read a Protobuf message in logs without the schema. JSON lets you debug by just reading the log. This is a real operational trade-off.

🎯 Interview One-Liner

"I'd use JSON for public-facing APIs prioritizing developer experience, and Protocol Buffers for internal service-to-service communication where the 3-10x size reduction and 20-100x faster parsing provide meaningful performance gains at scale — with Avro for event streaming where schema evolution is critical."

Interview Q&A