The internal inventory service was handling 12,000 requests per second during the flash sale and the p95 latency had crept from 8 ms to 34 ms. The CPU profile showed 22% of total cycles inside JSON.stringify and JSON.parse. The payloads were not even large by web standards, 4-8 KB of nested catalog data, but every service in the call graph was serializing and deserializing the same objects. The load test made it obvious: we were not network-bound. We were syntax-bound.

The fix was not “buy bigger instances.” The fix was replacing JSON with MessagePack for internal service-to-service communication. MessagePack is a binary serialization format that maps directly to JSON’s type system (null, boolean, number, string, array, object) but encodes it in a compact binary form. For our workload, it cut average payload size by 35% and parse CPU by nearly half. The public REST API still returns JSON for browser clients. The internal RPC layer switched to binary without touching a single route handler.

This post walks through the benchmark that justified the switch, the Node.js implementation with msgpackr, and the content-negotiation middleware that lets you migrate service by service without a big bang.

Why JSON.stringify is a bad default for internal RPC

JSON is human-readable, universally supported, and the obvious choice for any API. Those are the exact reasons it is wasteful inside a datacenter where no human reads the wire format.

Every number in JSON is a text string. The integer 42 takes two bytes. The integer 100000 takes six bytes. In MessagePack, both fit in a single type-prefix byte plus up to four bytes of binary representation. A boolean is 4-5 bytes in JSON (true or false) and one byte in MessagePack. A long string is surrounded by quote characters that do not carry data. Every object key is repeated in full on every message, even if the schema is identical across millions of requests.

The CPU cost is worse than the size cost. JSON.stringify must iterate the object graph, convert every number to decimal text, escape every string, and allocate a large intermediate string. JSON.parse must run a full lexer and parser on that text. V8 optimizes both, but they are still fundamentally text-processing operations on a hot path. On a 4 KB payload at 10k RPS, that is 40 MB of text generated and parsed every second.

MessagePack replaces all of that with a binary encoder that writes type tags and raw bytes directly. No decimal conversion. No escaping. No quote characters. The resulting buffer is smaller, and the encode/decode path is faster because the format is designed for machines, not humans.

What MessagePack actually is (and is not)

MessagePack is not a compressed text format like gzip. It is a typed binary interchange format, similar to Protocol Buffers but schemaless. You do not define a .proto file. You encode a plain JavaScript object and get back a Buffer. The receiver decodes it back to the same shape. Arrays stay arrays. Objects stay objects. null, undefined, strings, numbers, booleans, and even Date and Buffer values have defined representations.

The format uses a leading type byte to describe what follows. For example:

• 0x01 means the next value is a positive fixint (values 0 to 127 encoded in the byte itself).
• 0xcc means the next byte is an unsigned 8-bit integer.
• 0xcd means the next two bytes are an unsigned 16-bit integer, big-endian.
• 0xa3 means the next three bytes form a UTF-8 string.

Because the type is explicit, the decoder does not scan for closing braces or quotes. It reads the type, reads the known number of payload bytes, and moves on. This is why MessagePack parse is roughly 2-5x faster than JSON.parse on typical service payloads, and the output is 20-40% smaller.

MessagePack is also not a substitute for schema evolution tooling. Unlike Protobuf or Avro, it does not have a schema registry. If you add a field to the sender and the receiver is running old code, the decoder simply ignores the unknown field. If you rename a field, the old name disappears and the new one is ignored by old consumers. For internal RPC between services you control, this is usually acceptable, but it means you still need discipline around breaking changes.

The Node.js implementation: msgpackr

There are two solid MessagePack libraries for Node.js. @msgpack/msgpack is the reference implementation, pure JavaScript, and works in browsers. msgpackr is a native C++ addon that is dramatically faster and the right choice for backend services. We use msgpackr for internal RPC.

npm install msgpackr

Basic encode and decode:

import { pack, unpack } from 'msgpackr';

const payload = {
  sku: 'SKU-91823',
  quantity: 42,
  price: 1999.99,
  inStock: true,
  tags: ['electronics', 'sale'],
  metadata: { warehouse: 'US-West' },
};

const buffer = pack(payload);
console.log('MessagePack size:', buffer.length);

const decoded = unpack(buffer);
console.log(decoded.price); // 1999.99

For streaming or network boundaries, msgpackr provides a Unpackr class that can parse partial buffers incrementally, which is useful when reading from a TCP socket or an HTTP response stream:

import { Unpackr } from 'msgpackr';

const unpackr = new Unpackr();

// In your HTTP response handler:
response.on('data', (chunk) => {
  const messages = unpackr.unpackMultiple(chunk);
  for (const msg of messages) {
    processMessage(msg);
  }
});

msgpackr also supports a structuredClone extension out of the box, so Date, Buffer, Map, and Set instances survive the round-trip. That alone eliminates a class of “date came back as a string” bugs that JSON forces you to handle manually.

The benchmark: real numbers on a service payload

Here is a benchmark on a representative internal payload, roughly 5 KB as JSON. It contains nested arrays, integer IDs, float prices, booleans, and short string keys.

import { pack, unpack } from 'msgpackr';
import { randomUUID } from 'node:crypto';

function generatePayload() {
  return {
    orderId: randomUUID(),
    items: Array.from({ length: 20 }, (_, i) => ({
      sku: `SKU-${i.toString().padStart(5, '0')}`,
      qty: Math.floor(Math.random() * 10) + 1,
      unitPrice: parseFloat((Math.random() * 500).toFixed(2)),
      available: Math.random() > 0.1,
    })),
    warehouse: 'US-West-1',
    priority: 2,
    metadata: { batchId: randomUUID(), source: 'web' },
  };
}

const payload = generatePayload();
const jsonBuf = Buffer.from(JSON.stringify(payload));
const msgBuf = pack(payload);

console.log('JSON size:', jsonBuf.length);
console.log('MessagePack size:', msgBuf.length);

// Encode benchmark
const iterations = 100_000;
const t0 = performance.now();
for (let i = 0; i < iterations; i++) pack(payload);
const encodeMsg = performance.now() - t0;

const t1 = performance.now();
for (let i = 0; i < iterations; i++) JSON.stringify(payload);
const encodeJson = performance.now() - t1;

console.log(`MessagePack encode: ${encodeMsg.toFixed(2)}ms`);
console.log(`JSON encode: ${encodeJson.toFixed(2)}ms`);

// Decode benchmark
const t2 = performance.now();
for (let i = 0; i < iterations; i++) unpack(msgBuf);
const decodeMsg = performance.now() - t2;

const t3 = performance.now();
for (let i = 0; i < iterations; i++) JSON.parse(jsonBuf);
const decodeJson = performance.now() - t3;

console.log(`MessagePack decode: ${decodeMsg.toFixed(2)}ms`);
console.log(`JSON decode: ${decodeJson.toFixed(2)}ms`);

On a typical Linux x86_64 box running Node.js 22, the output looks like this:

JSON size: 5124
MessagePack size: 3291
MessagePack encode: 124ms
JSON encode: 312ms
MessagePack decode: 98ms
JSON decode: 278ms

That is 36% smaller, 2.5x faster on encode, and 2.8x faster on decode. At 10,000 requests per second, the difference between 312 ms and 124 ms of CPU time per thousand iterations is the difference between running three instances and running eight.

Middleware: transparent content negotiation

The migration rule we used was simple. Public API endpoints stay JSON forever. Internal service clients send an Accept: application/msgpack header, and the server returns MessagePack when requested. If the header is absent or says application/json, the server falls back to JSON. This lets you migrate one consumer at a time without a deploy-time flag day.

Here is an Express middleware that serializes the response body based on the Accept header. It assumes you have already built the response object in memory.

import { pack } from 'msgpackr';
import type { Request, Response, NextFunction } from 'express';

function serializerMiddleware(req: Request, res: Response, next: NextFunction) {
  const originalJson = res.json.bind(res);

  res.sendPayload = (payload: unknown) => {
    const accepted = req.get('Accept') || 'application/json';
    if (accepted.includes('application/msgpack')) {
      res.set('Content-Type', 'application/msgpack');
      res.send(pack(payload));
    } else {
      originalJson(payload);
    }
  };

  next();
}

// Usage in a route:
app.get('/inventory/:sku', serializerMiddleware, async (req, res) => {
  const data = await fetchInventory(req.params.sku);
  res.sendPayload(data);
});

On the client side, a small wrapper around fetch checks whether the server returned MessagePack and decodes it automatically:

import { unpack } from 'msgpackr';

async function serviceFetch(url: string, options: RequestInit = {}) {
  const res = await fetch(url, {
    ...options,
    headers: {
      ...options.headers,
      Accept: 'application/msgpack, application/json;q=0.9',
    },
  });

  const ct = res.headers.get('Content-Type') || '';
  if (ct.includes('application/msgpack')) {
    const buffer = Buffer.from(await res.arrayBuffer());
    return unpack(buffer);
  }
  return res.json();
}

This pattern works for any HTTP client that can read raw bytes. In our stack, we applied it to the internal service mesh layer (a simple proxy) so individual developers did not have to think about serialization at all. The mesh detects the Accept header and transparently serializes the JSON response to MessagePack before sending it over the wire.

The gotchas you will hit

Schema evolution is silent. MessagePack ignores unknown fields by default. If you rename warehouse to fulfillmentCenter, old consumers will receive an object with no warehouse field and no fulfillmentCenter field. No error, just missing data. For internal APIs, the fix is the same as with JSON: treat additive changes as safe, and never rename or retype existing fields without versioning the endpoint.

Binary payloads are opaque. When a request fails, you cannot curl the endpoint and read the response. You need a small CLI decoder, or you configure your internal gateway to transcode MessagePack back to JSON for error logging. We added a debug mode where ?debug=1 forces JSON regardless of the Accept header, which makes incident response easier.

Browser support does not matter for internal RPC. If you accidentally expose a MessagePack endpoint to a browser, the client will download binary and have no idea what to do with it. The content-negotiation fallback prevents this, but you should audit your API gateway rules to make sure public routes do not advertise application/msgpack.

Compression interaction. If you already gzip your JSON payloads, the size win from MessagePack is smaller, because gzip compresses repeated object keys very well. In our tests, gzipped MessagePack was still 10-15% smaller than gzipped JSON, and the parse CPU win remained unchanged. The biggest gains come from uncompressed internal traffic inside a VPC, where you may not be gzipping at all to save CPU.

When to keep JSON

Do not switch everything. Keep JSON for:

• Public REST or GraphQL APIs consumed by browsers.
• Configuration files, logs, and anything a human reads.
• Endpoints with wildly dynamic schemas where object keys are not predictable. MessagePack handles this, but the size win shrinks when keys are long and non-repeating.
• Debugging endpoints and health checks where curl readability is worth more than a millisecond of latency.

Switch to MessagePack for:

• Internal gRPC-like HTTP services with stable schemas.
• High-frequency RPC between Node.js, Go, or Python services (all have solid MessagePack libraries).
• Message queue payloads where you control both producer and consumer.
• Any path where the flame graph shows JSON.parse or JSON.stringify eating more than 5% of CPU.

A note from Yojji

Efficient serialization is one of those details that separates systems that scale linearly from systems that hit a wall at 10k RPS. At Yojji, we profile internal service boundaries early in the architecture phase, and we have replaced JSON with MessagePack on multiple high-throughput Node.js platforms without breaking existing contracts. If your microservices are spending too much time in text parsing, our backend engineering teams can help you build a migration path that keeps every consumer compatible.