#Go encoding/gob in Production: Type-Aware Streams, Compatibility, and Trust Boundaries

encoding/gob is Go's native binary serialization format for exchanging Go values.

It is compact, self-describing, type-aware, and particularly effective when one Go process maintains a long-lived stream with another Go process. It is also the serialization format used by packages such as net/rpc.

But Gob is not simply a function that converts a value into bytes.

Gob maintains stream state, transmits type information, applies its own compatibility rules, may reuse or merge destination values during decoding, and can allocate memory according to the incoming data.

That makes Gob convenient for internal Go systems—but it also means that its stream semantics, schema evolution, resource consumption, and trust boundaries must be treated as part of the production architecture.

The central model is:

Go Value
    │
    ▼
encoding/gob
    ├── type information
    ├── value encoding
    ├── stream state
    └── Go type compatibility
    │
    ▼
Gob Stream
    │
    ▼
encoding/gob
    │
    ▼
Go Value

Gob does not merely encode bytes. It transports Go values through a stateful, type-aware stream. That convenience is its strength—and the reason its stream state, type system, allocation behavior, schema compatibility, and trust boundary must be treated as part of the production architecture.

#1. Gob Is a Type-Aware Stream

Gob is designed around Encoder and Decoder:

enc := gob.NewEncoder(w)
dec := gob.NewDecoder(r)

Values are then transmitted through the stream:

if err := enc.Encode(value); err != nil {
    return err
}

and received with:

if err := dec.Decode(&value); err != nil {
    return err
}

Gob streams are self-describing. Type information is transmitted as needed, allowing the decoder to reconstruct values without requiring an independently maintained byte layout.

This is fundamentally different from a fixed binary protocol such as:

4-byte length
2-byte version
8-byte timestamp
32-byte identifier
N-byte payload

where the protocol explicitly defines every byte.

Gob instead defines a higher-level value representation.

That makes it excellent for internal Go-to-Go communication and less suitable when the wire representation itself is a long-lived public contract.

#2. Reuse the Encoder

Gob is most effective when an Encoder is reused for a stream.

Prefer:

enc := gob.NewEncoder(conn)

for {
    msg, err := nextMessage()
    if err != nil {
        return err
    }

    if err := enc.Encode(msg); err != nil {
        return err
    }
}

over repeatedly constructing new encoders:

for {
    enc := gob.NewEncoder(conn)
    if err := enc.Encode(msg); err != nil {
        return err
    }
}

The encoder maintains stream state and can amortize type information and codec construction across multiple values.

Gob's implementation compiles codecs for encountered types and is particularly efficient when one encoder sends a sequence of values.

Therefore:

An Encoder is a stream component, not merely a serialization helper.

#3. Gob Is Not a Stateless Serialization Function

It is tempting to model serialization as:

value → bytes

Gob is better understood as:

Encoder State + Value
        │
        ▼
   Gob Stream
        │
        ▼
Decoder State + Destination

Type definitions and values participate in the same stream.

Consequently, the meaning of a Gob byte sequence can depend on the stream context in which it occurs.

This has several architectural consequences:

• reuse an encoder for a logical stream;
• do not assume each Encode result is an independent canonical blob;
• preserve stream ordering;
• define stream ownership explicitly;
• do not casually concatenate or manipulate Gob fragments;
• treat decoder state as part of the protocol state.

Gob is therefore closer to a typed stream protocol than a stateless serialization API.

#4. Compatibility Is Based on Structure, Not Field Order

Gob matches struct fields by name rather than by source declaration order.

For example:

type RequestV1 struct {
    ID   string
    User string
}

can evolve into:

type RequestV2 struct {
    User  string
    ID    string
    Trace string
}

The field order changed, and a new field was added.

Gob can still decode the common fields because the compatibility model is based on field names and compatible types.

Sender-only fields can be ignored by the receiver.

Receiver-only fields retain their zero value when absent from the stream.

This is useful for incremental evolution of internal Go services.

But structural compatibility is not the same thing as application compatibility.

#5. Structural Compatibility Does Not Mean Arbitrary Schema Evolution

Consider:

type MessageV1 struct {
    Count int
}

and:

type MessageV2 struct {
    Count int64
}

This can be compatible with Gob's type rules when the transmitted value fits the destination type.

But changing:

Count int

to:

Count string

is not a compatible schema change.

More importantly, even a Gob-compatible change can be an application-level breaking change.

For example:

Count int

might originally mean:

number of records

and later:

Count int64

might be interpreted as:

number of bytes

Gob may successfully decode the value while the application semantics have changed completely.

Therefore:

Gob compatibility is a serialization property, not a guarantee of application compatibility.

Schema evolution still requires protocol and application discipline.

#6. Gob Encodes Values, Not Go Memory Layout

Gob does not serialize a Go struct by dumping its in-memory representation.

This would be unsafe and non-portable because Go memory layout contains implementation details such as:

• padding;
• pointer representation;
• architecture-dependent layout;
• runtime metadata;
• object addresses.

Instead, Gob operates on the logical Go value.

This means:

type User struct {
    ID   uint64
    Name string
}

does not mean:

memory bytes of User

It means:

Gob representation of the logical fields

That distinction is important when comparing Gob with low-level binary protocols.

#7. Decoder Semantics Matter

A decoder does not necessarily construct every destination value from scratch.

Gob may decode into an existing value and merge decoded information into it.

For example:

var dst Config

if err := dec.Decode(&dst); err != nil {
    return err
}

If application semantics require a completely fresh object, make that explicit:

var dst Config

for {
    dst = Config{}

    if err := dec.Decode(&dst); err != nil {
        return err
    }

    process(dst)
}

This avoids accidentally allowing previous state to survive when fields are absent from a later Gob value.

The important production rule is:

Do not assume Decode means “replace every byte of the destination.”

Understand the merge semantics of the destination type.

#8. Slice Decoding Can Reuse Existing Capacity

Gob can reuse the capacity of an existing slice when decoding.

For example:

items := make([]Item, 0, 1024)

if err := dec.Decode(&items); err != nil {
    return err
}

This can reduce allocation pressure when repeatedly decoding similarly sized values.

But reuse also means the destination's previous state can matter.

If object ownership or lifetime is complicated, explicit replacement may be clearer than relying on reuse.

In performance-sensitive paths, benchmark both approaches rather than assuming reuse is always beneficial.

#9. Gob Allocation Is Driven by Input

Decoding is not a zero-cost operation.

An incoming Gob value can cause allocations for:

• slices;
• maps;
• strings;
• nested structs;
• interface values;
• dynamically constructed values.

This makes the decoder an input-driven resource consumer.

A useful production model is:

Untrusted Input
      │
      ▼
   Gob Decode
      │
      ├── CPU
      ├── Memory
      └── Object Graph

Therefore, decoding belongs inside a resource budget.

#10. Do Not Put Untrusted Gob Directly on an Unbounded Network Stream

Gob is not an authentication, authorization, or resource-control mechanism.

A remote peer can influence:

• encoded values;
• collection sizes;
• nested structures;
• interface values;
• custom decoding behavior;
• memory allocation;
• CPU consumption.

Therefore:

Internet
   │
   ▼
Gob Decoder

is an incomplete architecture.

A safer model is:

Network
   │
   ▼
Authentication / Authorization
   │
   ▼
Transport Limits / Deadlines
   │
   ▼
Message Framing
   │
   ▼
Gob Decoder
   │
   ▼
Protocol Validation
   │
   ▼
Application

The decoder should not be the first or only defensive layer.

#11. Frame Gob When the Transport Requires Explicit Message Limits

Gob is already a stream format.

That does not mean every application needs an additional frame.

If the transport is already a long-lived Gob stream and its resource policy is defined at the connection level, Gob's own stream semantics may be sufficient.

But if the application requires:

each logical message must consume at most N bytes

then an outer envelope is useful.

Conceptually:

┌─────────────────────────────┐
│ Message Length              │
├─────────────────────────────┤
│ Gob Payload                 │
└─────────────────────────────┘

The outer framing layer can then enforce:

payload length <= MaxMessageSize

before handing the payload to Gob.

This separates two concerns:

Framing
    → How many bytes belong to this message?

Gob
    → How are Go values represented inside those bytes?

That separation becomes especially valuable when transport-level limits must be enforced independently of Gob's internal representation.

#12. Gob's Type System Is Part of the Stream

Gob transmits type information as part of the stream.

This means the protocol is not merely:

value bytes

but:

type information
+
value information

The decoder therefore needs to understand the type definitions that occur in the stream.

This is one reason Gob works so well for Go-to-Go communication: the serialization format understands Go's structural types directly.

It is also one reason Gob is not an ideal choice for language-neutral public protocols.

#13. gob.Register Is a Schema Boundary for Interface Values

Interface values introduce an additional layer.

For example:

type Event interface {
    Event()
}

type UserCreated struct {
    ID string
}

func (UserCreated) Event() {}

When an interface contains a concrete value, Gob needs the concrete type information.

Applications commonly register such concrete types:

gob.Register(UserCreated{})

The registered type name becomes part of the serialized interface representation.

Therefore, registration is not merely initialization boilerplate.

It is part of the protocol surface.

A useful architectural rule is:

Changing concrete types stored inside interfaces can be a protocol change even when the surrounding interface remains unchanged.

Keep registration deterministic and centralized.

#14. Interface Values Increase the Trust Boundary

Interfaces deserve additional scrutiny because the concrete type is selected by information carried in the stream.

This creates a dynamic decoding path:

Gob Stream
    │
    ▼
Interface Type
    │
    ▼
Concrete Go Type
    │
    ▼
Decode

This is powerful for internal RPC systems and event streams.

It is less attractive for broadly exposed untrusted protocols.

Do not treat gob.Register as an authorization mechanism.

Type registration determines what Gob can decode—not whether the decoded object is allowed to perform a particular application action.

#15. Custom GobEncode / GobDecode Need Protocol Discipline

Types can customize Gob encoding:

type GobEncoder interface {
    GobEncode() ([]byte, error)
}

and decoding:

type GobDecoder interface {
    GobDecode([]byte) error
}

These methods execute application code as part of serialization/deserialization.

That means they are part of the input-processing path.

A custom decoder should therefore:

• validate input;
• bound internal allocations;
• reject malformed representations;
• avoid excessive CPU work;
• avoid unexpected external side effects;
• return errors rather than panic on normal malformed input.

The same principle applies when Gob uses encoding.BinaryMarshaler / encoding.BinaryUnmarshaler.

A custom decoder is an input parser. Treat it like one.

#16. Gob and encoding.BinaryMarshaler

Gob can interact with types implementing:

encoding.BinaryMarshaler

and:

encoding.BinaryUnmarshaler

when the type does not provide the more specific Gob interfaces.

This allows existing types with binary representations to participate in Gob.

But the abstraction boundary should remain clear.

A MarshalBinary representation does not automatically become a stable application protocol.

If a type's binary representation changes, the resulting Gob compatibility and application compatibility must be evaluated together.

#17. Gob Is Go-Specific by Design

Gob's greatest advantage is also its largest limitation.

It understands Go's type system:

• structs;
• slices;
• maps;
• interfaces;
• integers;
• floating-point values;
• strings;
• recursive types.

That makes it natural for:

Go Service
      │
      ▼
    Gob
      │
      ▼
Go Service

It is much less attractive for:

Go
 │
 ▼
Gob
 │
 ▼
Rust / Java / Python / C++

If multiple languages are first-class protocol participants, use a format designed around an explicit language-neutral schema.

Gob should generally be considered an internal Go protocol format.

#18. Gob Is Good for Internal Go Systems

Good use cases include:

• internal RPC;
• Go-only service communication;
• temporary IPC;
• internal queues;
• short-lived cache entries;
• test fixtures;
• Go-specific tooling;
• controlled persistence where schema ownership is clear.

The strongest use case is usually:

Go application
      │
      ▼
Gob
      │
      ▼
Go application

where the participating systems share ownership of the Go type definitions.

#19. Be Careful Using Gob as a Persistent Storage Format

Gob can be written to disk:

f, err := os.Create(path)
if err != nil {
    return err
}
defer f.Close()

enc := gob.NewEncoder(f)

if err := enc.Encode(value); err != nil {
    return err
}

But persistence changes the problem.

A network stream may live for seconds or hours.

A database or disk file may need to remain readable for:

• months;
• years;
• multiple application versions;
• disaster recovery;
• migrations;
• operational debugging.

Gob provides useful structural compatibility, but it should not be mistaken for a complete persistent-schema migration system.

For long-lived storage, prefer an explicit format when:

• schema evolution is complex;
• multiple versions must coexist;
• data must be inspected independently;
• other languages need access;
• canonical representation matters;
• long-term archival is required.

#20. If Gob Is Used for Temporary Storage, Add an Outer Versioned Envelope

Gob can still be a reasonable payload format for controlled temporary storage such as:

• local caches;
• temporary snapshots;
• internal WAL segments;
• rebuildable indexes;
• short-lived spill files.

In these cases, put Gob inside an explicit application envelope:

┌──────────────────────────────┐
│ Magic                        │
│ Format Version               │
│ Flags                        │
│ Payload Length               │
│ Integrity Metadata           │
├──────────────────────────────┤
│ Gob Payload                  │
└──────────────────────────────┘

For example:

MAGIC   = "GOB1"
VERSION = 1
LENGTH  = N
PAYLOAD = Gob stream

The purpose is not to make Gob itself version-aware.

The purpose is to make the container format version-aware.

This gives the storage layer an early decision point:

Read Header
    │
    ├── unknown magic → reject
    ├── unsupported version → reject / migrate
    ├── invalid length → reject
    └── valid envelope
             │
             ▼
         Gob Decode

An outer length field also allows the application to enforce resource limits before decoding.

Integrity metadata can protect the envelope against corruption or accidental truncation.

For long-term data, however, a version header does not eliminate the need for schema migration and compatibility testing.

Versioning the container does not make the payload schema automatically compatible.

#21. Gob Integer Encoding Is Not encoding/binary

Gob's integer representation is its own encoding scheme.

It does not preserve distinctions such as:

int8
int16
int32
int64

as fixed-width wire types.

Instead, Gob represents integers in a compact variable-length form.

This should not be confused with encoding/binary.

encoding/binary answers:

How should this integer be represented as bytes using a selected byte order?

Gob answers:

How should this Go value participate in a self-describing Go value stream?

They solve different problems.

#22. Structural Compatibility and Scalar Compatibility Are Different

Gob's structural matching by field name is only one part of compatibility.

The scalar type rules matter too.

For example:

Sender        Receiver       Gob compatibility
------------------------------------------------
int           int64          yes, if value fits
int64         int32          yes, if value fits
uint64        uint32         yes, if value fits
float64       float32        yes, if value fits
int           uint            no
int           float64        no
float64       int             no
string        []byte         no

The important distinction is:

Structural Compatibility
        +
Gob Scalar Compatibility
        +
Destination Range

A field with the same name is not automatically compatible.

For example:

type V1 struct {
    Count int
}

and:

type V2 struct {
    Count int64
}

can be compatible because Gob treats integers according to its own integer categories and checks whether the value can be represented by the destination type.

But:

type V2 struct {
    Count uint
}

is not simply an automatic signed-to-unsigned conversion.

Likewise:

float64 → int

is not treated as a normal numeric conversion.

Therefore:

Gob compatibility is not Go assignment compatibility.

Schema evolution should be evaluated against Gob's actual wire-type rules, not against what a Go programmer might expect a compiler conversion to do.

#23. Gob Omits Some Zero-Valued Struct Fields

Gob can omit zero-valued struct fields from the encoded representation.

This is an important implementation detail when reasoning about compatibility and encoded size.

It also reinforces the principle that Gob output should not be treated as a fixed byte layout.

Do not build application logic around assumptions such as:

field X always occupies N bytes

unless an explicit outer protocol defines that property.

#24. Maps, Slices, and Nested Structures Can Amplify Input

A small encoded message can result in a substantially larger in-memory object.

For example:

Encoded Input
     │
     ▼
Nested structures
     │
     ├── slices
     ├── maps
     ├── strings
     └── interfaces
     │
     ▼
Large Object Graph

Therefore:

encoded size
    ≠
memory consumption

This is particularly important for untrusted input.

Resource controls should consider:

• maximum message size;
• maximum number of messages;
• connection lifetime;
• memory budget;
• application-level collection limits;
• request deadlines.

A byte limit alone is not always sufficient.

#25. Gob Does Not Replace Context Cancellation

Gob does not provide a general mechanism for interrupting arbitrary decode work through context.Context.

For network communication, cancellation should usually be enforced at the transport boundary.

For example:

if err := conn.SetReadDeadline(time.Now().Add(timeout)); err != nil {
    return err
}

if err := dec.Decode(&msg); err != nil {
    return err
}

At higher layers, use context cancellation to decide whether the operation should continue.

The architectural boundary is:

Context
   │
   ▼
Transport / Operation Lifetime
   │
   ▼
Gob Decoder

Do not assume that passing a context around application code automatically interrupts an already-running Gob decode.

#26. Encoder Concurrency, Writer Buffering, and Stream Ownership

gob.Encoder is safe for concurrent use.

This means multiple goroutines can call:

enc.Encode(v)

without corrupting the Gob stream.

The encoder protects the encoding/write operation so that individual Gob items are emitted atomically.

But concurrency safety is not the same as protocol ownership.

Consider:

Goroutine A ─┐
             │
Goroutine B ─┼──► gob.Encoder ───► Writer
             │
Goroutine C ─┘

The resulting stream will remain structurally valid.

But the application has not necessarily defined whether:

A → B → C

or:

C → A → B

should be observed by the receiver.

The mutex prevents interleaving and corruption.

It does not define business ordering.

#26.1 Prefer a Single Writer When Ordering Matters

When message ordering is part of the protocol, a common architecture is:

Workers
   │
   ▼
Message Queue
   │
   ▼
Single Writer Goroutine
   │
   ▼
gob.Encoder
   │
   ▼
io.Writer

For example:

type Outgoing struct {
    Value any
}

func writeLoop(
    enc *gob.Encoder,
    ch <-chan Outgoing,
) error {
    for msg := range ch {
        if err := enc.Encode(msg.Value); err != nil {
            return err
        }
    }

    return nil
}

The queue establishes the ordering policy.

The writer goroutine establishes stream ownership.

The Encoder performs serialization.

These are separate responsibilities.

#26.2 Gob Does Not Own Writer Buffering

Gob writes encoded messages to the io.Writer supplied to NewEncoder.

Gob itself does not define a general Flush() operation.

If the application wraps the underlying writer in bufio.Writer:

bufw := bufio.NewWriter(conn)
enc := gob.NewEncoder(bufw)

then the buffering policy belongs to bufio.Writer.

The application must explicitly flush it when the protocol requires the data to become visible to the underlying writer:

if err := enc.Encode(msg); err != nil {
    return err
}

if err := bufw.Flush(); err != nil {
    return err
}

This distinction is important:

Gob
    → encodes and writes

bufio.Writer
    → buffers and flushes

net.Conn
    → transports bytes

Do not attribute buffering or flushing behavior to Gob itself.

#26.3 Concurrency Safety Does Not Solve Backpressure

A shared Encoder may be safe to call concurrently, but that does not solve:

• slow receivers;
• queue growth;
• blocked writes;
• memory pressure;
• ordering requirements;
• connection shutdown;
• writer ownership;
• cancellation.

A production stream therefore needs explicit policies for:

Ordering
Backpressure
Queue Capacity
Write Timeout
Shutdown
Error Propagation

Gob only solves the serialization part.

#27. Gob Output Should Not Be Treated as a Canonical Representation

Gob is designed for communication, not canonical serialization.

Do not assume that Gob output should serve as:

• a stable cryptographic signature input;
• a canonical cache key;
• a permanent content hash;
• a cross-version byte identity.

If an application needs canonical bytes, define a canonical representation explicitly.

The architectural distinction is:

Gob
  → efficient Go value transport

Canonical Encoding
  → stable byte-level representation

Those are different requirements.

#28. Common Production Failure Modes

#Failure 1: Creating a new Encoder for every message

This wastes the benefits of stream state and repeated type information.

Better: reuse the Encoder for a logical stream.

#Failure 2: Assuming Encoder concurrency defines message ordering

The stream may remain valid while business ordering becomes nondeterministic.

Better: use a queue and single writer when ordering matters.

#Failure 3: Assuming Gob has a Flush method

Gob does not own buffering.

Better: flush the actual buffered writer when one is used.

#Failure 4: Treating field-name compatibility as complete schema compatibility

The field may match by name while its scalar type or application meaning has changed.

Better: test actual Gob compatibility and application semantics.

#Failure 5: Reusing a destination without understanding merge semantics

Previous data may survive in ways the application does not expect.

Better: explicitly reset or replace destinations when required.

#Failure 6: Assuming encoded size equals memory cost

A compact Gob value can expand significantly in memory.

Better: budget memory independently of wire size.

#Failure 7: Decoding arbitrary remote Gob input

The decoder becomes an uncontrolled resource consumer.

Better: authenticate, frame, bound, deadline, decode, then validate.

#Failure 8: Treating gob.Register as security

Registration controls type availability, not authorization.

Better: validate the decoded object and enforce application permissions separately.

#Failure 9: Using Gob as a public cross-language protocol

Gob is optimized for Go's type system.

Better: use an explicit language-neutral schema when interoperability matters.

#Failure 10: Using raw Gob as a permanent storage format

Future migrations become coupled to Go type evolution.

Better: use an explicit versioned storage format or put Gob inside a versioned envelope for controlled temporary storage.

#Failure 11: Writing custom GobDecode without input limits

Custom decoders can introduce their own memory and CPU risks.

Better: treat every custom decoder as an untrusted-input parser.

#Failure 12: Assuming Gob bytes are canonical

Byte-level identity is not Gob's contract.

Better: define a separate canonical encoding when signatures or stable hashes require it.

#29. Production Architecture

A production Gob system should look more like this:

                    ┌──────────────────────┐
                    │   Application Logic  │
                    └──────────┬───────────┘
                               │
                    validation / authorization
                               │
                    ┌──────────▼───────────┐
                    │ Message / Queue Layer│
                    └──────────┬───────────┘
                               │
                    ordering / backpressure
                               │
                    ┌──────────▼───────────┐
                    │ Single Writer Policy │
                    └──────────┬───────────┘
                               │
                    ┌──────────▼───────────┐
                    │    gob.Encoder       │
                    └──────────┬───────────┘
                               │
                    optional buffering
                               │
                    ┌──────────▼───────────┐
                    │     io.Writer        │
                    └──────────┬───────────┘
                               │
                         Transport
                               │
                    ┌──────────▼───────────┐
                    │ Framing / Limits     │
                    └──────────┬───────────┘
                               │
                    ┌──────────▼───────────┐
                    │    gob.Decoder       │
                    └──────────┬───────────┘
                               │
                    decode / resource limits
                               │
                    ┌──────────▼───────────┐
                    │ Protocol Validation  │
                    └──────────┬───────────┘
                               │
                    ┌──────────▼───────────┐
                    │   Application State  │
                    └──────────────────────┘

Each layer has a distinct responsibility.

Gob should not be expected to provide the responsibilities of the surrounding layers.

#30. Production Rules

Use these rules when deploying encoding/gob:

1. Treat Gob as Go value transport, not a language-neutral wire protocol.

2. Reuse gob.Encoder for a long-lived logical stream.

3. Understand that Gob is stateful and type-aware.

4. Do not treat each Encode call as an independent canonical byte representation.

5. Understand field-name-based structural compatibility.

6. Do not confuse structural compatibility with application compatibility.

7. Understand Gob's scalar compatibility rules before evolving field types.

8. Remember that Gob compatibility is not Go assignment compatibility.

9. Reset or replace decode destinations when merge semantics are undesirable.

10. Treat decoding as an input-driven resource operation.

11. Bound network messages when strict per-message resource limits are required.

12. Use transport deadlines and connection limits for network lifetime control.

13. Treat interface values and gob.Register as part of the protocol surface.

14. Treat custom GobDecode implementations as untrusted-input parsers.

15. Validate decoded values before allowing them into application state.

16. Do not confuse Gob's concurrency safety with application-level ordering.

17. Use a single writer when deterministic message ordering matters.

18. Remember that Gob does not own buffering or flushing; the supplied io.Writer does.

19. Define backpressure and queue ownership separately from serialization.

20. For temporary persistence, put Gob inside an explicit versioned envelope when useful.

21. For long-lived persistence, treat Gob schema evolution as a migration problem.

22. Do not rely on Gob as a permanent cross-language storage format.

23. Do not use Gob output as a canonical byte representation without an explicit canonicalization contract.

24. Keep authentication, authorization, framing, resource limits, and protocol validation outside Gob itself.

#Conclusion

encoding/gob is unusually convenient because it understands Go values rather than forcing the application to manually describe every byte.

That convenience makes it excellent for controlled Go-to-Go systems.

But the same abstraction hides several properties that matter in production:

• stream state;
• transmitted type information;
• structural compatibility;
• scalar compatibility;
• destination merge semantics;
• allocation behavior;
• interface registration;
• custom decoding;
• concurrency;
• buffering;
• ordering;
• backpressure;
• persistence and schema evolution.

The right mental model is therefore not:

Gob = serialize(value)

but:

Gob = typed value stream
     + stream state
     + compatibility rules
     + decoder resource consumption

And the production architecture should be:

Transport
   ↓
Framing / Limits
   ↓
Gob
   ↓
Validation
   ↓
Application

with concurrency, ordering, buffering, persistence, and trust boundaries explicitly owned by the surrounding system.

Use Gob when Go-to-Go value transport is the problem. Do not make Gob responsible for protocol semantics that belong to the system around it.