Compression tradeoffs

Compression makes bytes smaller, and every byte you save is a byte you do not send, store or read. The price is CPU time on both ends. Whether compression is worth it depends on how big the payload is, how much CPU you have and where the bottleneck sits.

The big idea

Compression is a trade between three things: size, speed and the CPU you spend. Some codecs compress hard but slowly. Others are fast but save less. You choose the point that fits the bottleneck: network, disk or CPU.

Walking through a response

Take a 4 KB JSON response. Compressed with gzip at level 6, it might shrink to about 800 bytes, and cost a few hundred microseconds of CPU. These numbers are illustrative.

size saved per response  = 4,000 − 800 = 3,200 bytes
CPU per response         ≈ 0.3 ms
at 50,000 responses/s:
  CPU needed ≈ 50,000 × 0.3 ms = 15 seconds of CPU every second ≈ 15 cores

Fifteen cores spent on compression is a real cost. That is why reverse proxies and CDNs often own HTTP compression, so the application servers do not pay for it.

Now flip the case. Storing 1 TB of JSON logs at a 5 to 1 ratio saves about 800 GB of disk. A batch job can compress that data during off-peak hours, and the saving is almost always worth the CPU.

Rules of thumb

• Compress multi-kilobyte payloads when CPU is cheaper than the network or the disk.
• Skip compression for tiny messages that are already dense binary. A message of a few dozen bytes may gain nothing, and the CPU is wasted.
• Expect different ratios by format. Text JSON often shrinks 3 to 8 times. Binary Protobuf often shrinks 1.5 to 3 times. Measure your own payloads.
• Use a dictionary for small, repetitive messages. Train a zstd dictionary on sample traffic, ship it once, and compress each message against it. Each small message then shares the common parts.

Order matters

Compress after serialization: serialize to JSON or Protobuf, then compress the bytes. Formats like Parquet already compress each column page internally. Compressing that again with gzip rarely helps and can make things worse.

Measuring the trade

Measure on your own data, at your real size and rate. Check three numbers.

1. The compressed size, as a ratio.
2. The CPU time per message, on both the encoder and the decoder.
3. The effect on the bottleneck, such as network bytes per second or disk used.

If the switch from JSON to Protobuf saves more bytes than a higher gzip level, the format change wins. Profile serialization and compression separately to see which one costs more.

Common mistakes

• Compressing everything by default. Tiny messages and already-compressed data gain little.
• Picking the highest level without measuring. Higher levels can cost much more CPU for a small gain.
• Compressing twice. Gzip on top of Parquet or another compressed format wastes CPU.
• Forgetting the decoder. Both ends pay the CPU, not only the sender.

Check yourself

1. Why might compressing a 40-byte binary message make things worse? There is little redundancy to remove, and the codec's fixed overhead can make the output larger, while CPU is still spent.
2. A 4 KB response compresses to 800 bytes. At 1,000 responses per second, how many bytes per second are saved? 3,200 × 1,000 = 3.2 MB per second.

Key takeaways

• Compression trades CPU for bytes. Pick a codec that fits the bottleneck.
• Multi-kilobyte payloads usually gain; tiny dense messages usually do not.
• Measure the ratio and the CPU cost on your own data.
• Compress after serialization, not on top of formats that already compress.

Further learning

Next, read serialization pitfalls for the production bugs that come from the formats and their encodings, including integers in JSON and checksums that are not security.