Message Serialisation

Also Known As

TL;DR

Explanation

Message serialisation formats: JSON — human-readable, schema-free, widely supported, but verbose (35 bytes for a simple event). MessagePack — binary JSON, 2-3x smaller. Avro — schema stored in a schema registry; consumer must have schema; excellent for Kafka; schema evolution rules prevent breaking consumers. Protocol Buffers (Protobuf) — strongly typed .proto schema, 5-10x smaller and faster than JSON, excellent cross-language support. Never use PHP serialize() for messages — PHP-only format and a deserialization vulnerability source.

Common Misconception

Why It Matters

Common Mistakes

• PHP serialize() for messages — PHP-only, insecure deserialization vulnerability
• No schema validation for JSON messages — malformed messages corrupt consumer state silently
• Avro without a schema registry — consumers need schemas; registry provides versioned schema access
• Changing Protobuf field numbers — field numbers are permanent; changing breaks all existing consumers

Code Examples

// PHP serialize — PHP-only, deserialization risk:
$message = serialize(['order_id' => 42, 'amount' => 99.99]);
$queue->publish($message);
// Cannot consume from Node.js, Python, Go services
// Consumer must unserialize() — deserialization vulnerability

// JSON — simple, cross-language:
$message = json_encode(['order_id' => 42, 'amount' => 99.99]);

// Protobuf — typed, compact, cross-language:
// payment.proto: message PaymentEvent { int64 order_id = 1; double amount = 2; }
$event = new PaymentEvent();
$event->setOrderId(42);
$event->setAmount(99.99);
$binary = $event->serializeToString(); // ~10 bytes vs JSON ~35 bytes

References

• ↗ https://developers.google.com/protocol-buffers

Tags

Related Terms