An events pipeline carries 2 billion events a day. Each event is JSON with 25 fields whose names average 14 characters. Roughly how many bytes a day go on field names alone, before compression?

The assumptions, stated

• 25 fields per event, names averaging 14 characters.
• Each key on the wire costs the name plus the surrounding quotes and the colon: about 17 bytes.
• 2 × 10⁹ events a day.
• Uncompressed, which is the number we are asked for and not the number you pay.

The arithmetic

25 × 17 ≈ 425 bytes of key overhead per event.

425 × 2 × 10⁹ = 8.5 × 10¹¹ bytes ≈ 850 GB a day, or roughly 310 TB a year, spent transmitting the same 25 strings over and over.

Which assumption dominates the error

Compression, by a wide margin, and it works in your favour. Field names repeat perfectly across records, which is the ideal case for a dictionary-based compressor. Batching similar records and compressing with a general-purpose codec typically removes most of this overhead, so the number you actually pay is a fraction of 850 GB.

That is the useful conclusion: the first lever is a configuration change, not a schema migration.

Why the other options fail

• 8.5 GB is off by two orders of magnitude and corresponds to about 20 million events a day — the right method applied to the wrong traffic figure, which is the most common arithmetic slip in capacity work.
• 85 GB treats the per-event key overhead as about 42 bytes rather than 425, which is what you get from counting one field instead of 25.
• 8.5 TB would require roughly 4,250 bytes of key overhead per event, which is 250 fields, not 25.

What the number rules in and out

It rules in compression as the first move, and it rules out treating a format migration as the obvious answer. Moving to a binary format with numeric field tags removes the names entirely, taking per-event key cost from roughly 425 bytes to tens of bytes — but it buys a schema registry, a code generation step, and the permanent loss of a payload a human can read during an incident.

The decision rule: compress first, because it is one configuration change and reversible. Move to a binary format only if the remaining bytes still dominate the bill, or if parsing CPU is the constraint — which is frequently the real reason to switch. Parsing JSON at billions of events a day is a substantial and often unexamined CPU line item, and binary decoding is several times cheaper.

When not to switch formats at all

Any payload a human debugs by eye, and any interface crossing an organisational boundary where the schema cannot be reliably distributed to the other side. The bytes saved are worth less than the hour lost the first time an incident requires someone to read the message.