Serialization and Deserialization: How Data Travels Between Systems
Your application works with objects.
The network works with bytes.
So how does this:
const user = {
name: "Vishal",
age: 23,
active: true
};
travel from one system to another?
The answer involves serialization and deserialization.
What Is Serialization?
Serialization is the process of converting structured application data into a representation that can be transmitted or stored.
For example:
Application Object
↓
Serialization
↓
JSON
A JavaScript object:
const user = {
name: "Vishal",
age: 23
};
can become:
{
"name": "Vishal",
"age": 23
}
That JSON can then be sent through an API, stored, cached, or passed to another system.
What Is Deserialization?
Deserialization is the reverse process.
JSON
↓
Deserialization
↓
Application Data
For example:
const user = JSON.parse(json);
The receiving application takes the serialized representation and turns it back into data it can work with.
So the basic idea is:
Serialization
Object → Representation
Deserialization
Representation → Object
Why Do We Need It?
An object living inside one application's memory cannot simply be sent directly to another process.
Imagine:
Node.js Service
↓
???
↓
Python Service
The two systems need an agreed representation.
That's why formats such as:
JSON
XML
Protocol Buffers
MessagePack
Avro
CBOR
exist.
The important part isn't just choosing a format.
Both systems need to agree on what the data means and what its structure is.
Text vs Binary
Serialization formats can broadly be thought of as text-based or binary-based.
Text-based
JSON
XML
CSV
They're generally easier for humans to inspect and debug.
Binary-based
Protocol Buffers
MessagePack
Avro
CBOR
These are designed more for machine-oriented communication and can provide advantages in payload size or processing efficiency depending on the workload.
But:
Binary doesn't automatically mean faster.
The right choice depends on the system.
Serialization Is More Than APIs
You will encounter serialization in many places:
APIs
↓
Message Queues
↓
Microservices
↓
Caching
↓
Storage
↓
Event Systems
↓
IPC
Whenever structured data needs to cross a boundary or leave its current representation, serialization can become part of the process.
Where Does the OSI Model Fit?
Serialization has a conceptual relationship with the Presentation Layer (Layer 6) of the OSI model because that layer deals with data representation and transformation.
But there is an important distinction:
Modern web applications don't have a literal "serialization layer" sitting at OSI Layer 6.
The OSI model is a conceptual model, and modern Internet protocols don't map perfectly onto all seven OSI layers.
Serialization ≠ Encoding ≠ Encryption
These concepts are easy to mix up.
Serialization
"What representation should this data have?"
Encoding
"How should this representation become bytes?"
Encryption
"How do we protect the data?"
For example:
Application Object
↓
Serialization
↓
JSON
↓
Encoding
↓
Bytes
↓
Encryption
↓
Protected Data
Each solves a different problem.
The Complete Mental Model
A simplified journey looks like:
Application Data
↓
Serialization
↓
Representation
↓
Encoding
↓
Bytes
↓
Network
↓
Bytes
↓
Decoding
↓
Representation
↓
Deserialization
↓
Application Data
The network doesn't understand your JavaScript object.
It moves data represented as bytes.
Serialization is one of the bridges that allows the meaningful structure of application data to cross system boundaries.
Want the Full Technical Breakdown?
I went deeper into serialization formats, HTTP APIs, binary serialization, OSI layers, encoding, encryption, compression, data contracts, schema evolution, and how the complete journey works.
Read the full article on my portfolio:
Serialization and Deserialization: How Data Travels Between Systems
Applications deal with structured data. Systems exchange representations. Networks move bytes.
Serialization connects those worlds.
Thanks for reading till the end :) Hope it teaches you something valuable in your software engineering journey.
