What distinguishes a text encoding from a binary encoding on the wire, and what does each choice cost?
answer
- same values, different audience
- characters versus sized bytes
- grep, diff, hand-edit
- readability paid in bytes and CPU
- volume of the hop decides
basics
~20 sA text encoding writes values as readable characters you can grep, diff and hand-edit; a binary encoding packs them as raw sized bytes that are typically smaller and cheaper to parse, but unreadable without a decoder.
solid answer
~50 sBoth carry the same values; they differ in whether the bytes are meant for a person as well as a machine. A **text encoding** spells every value out in characters — digits for numbers, characters for strings, punctuation for structure — so anything that reads characters can read it: a log line, a diff in a ticket, an editor. A **binary encoding** writes values in machine shape — fixed-width or variable-length integers, length-prefixed strings, numeric field tags — which is typically much smaller and cheaper to decode, but opaque without the matching decoder. So the axis is **inspectability against cost**: you pay for readability in bytes and processor time, and you pay for compactness in how hard the hop is to debug. Which side wins is usually decided by the volume of that hop and by whether a human ever reads those bytes.
go deeper
Be able to say what each form looks like as bytes and name one concrete thing readability buys, such as grepping a captured message out of a log during an incident.
Explain the mechanics behind the size and decode difference: spelled-out field names and punctuation against numeric tags and lengths, character scanning against sized reads.
Argue the choice for a specific hop with rates and with who debugs it, and propose the hybrid where compact bytes travel but a rendering step keeps incident tooling readable.
Frame it as a platform default rather than a per-service decision: what the organisation loses in debuggability across hundreds of hops, and what tooling must exist before a compact default is fair.
## What the two words mean on the wire Any value that leaves memory becomes a flat run of bytes. The question is what those bytes spell. In a **text encoding**, each value is represented with characters from a character set — in practice a UTF-8 compatible one. The number twelve hundred travels as the four characters `1200`. A string travels as its own characters, wrapped in whatever delimiters the grammar uses. Structure is punctuation: brackets, commas, indentation, angle brackets. Field names are usually spelled out next to every value. In a **binary encoding**, each value is written in a machine-shaped form. An integer is a fixed-width group of bytes or a variable-length one; a string is a length followed by its bytes; structure is carried by numeric tags, lengths and offsets instead of punctuation. Field names, if they exist at all, live in a separate definition rather than in the message. Both are just bytes. The real difference is whether the bytes were designed to be read by a person as well as by a program. ## What readability actually buys 1. **You can grep it.** A message that ends up in a log line, a trace attribute or an error report is searchable with ordinary tools. 2. **You can diff it.** Two captured messages can be pasted side by side in a ticket and the differing field is visible to anyone reading the ticket. 3. **You can hand-edit and replay it.** Reproducing a bug often means changing one field of a captured message and sending it again — trivial in characters, awkward in packed bytes. 4. **Any tool reads it.** No generated decoder, no schema fetch, no version match between the message and the reader's definitions. 5. **The first debugging step is shallow.** During an incident, the time between capturing a message and understanding it is close to zero, and that is exactly the moment when the cost of tooling is highest. ## What it costs | Axis | Text encoding | Binary encoding | | --- | --- | --- | | Read a captured message without tooling | Yes | No | | Bytes on the wire | Larger: digits, repeated field names, punctuation | Typically smaller: sized fields, numeric tags | | Decode work per value | Scan characters, find the end, convert digits | Read a known width, or skip by a stored length | | Reader needs an external definition | Usually not | Often yes | | Carrying raw bytes | Must be re-encoded into a safe character alphabet | Native | | Hand-editing a captured message | Practical | Impractical | Two honest qualifications belong in the answer. First, *typically* smaller is not *always* smaller: a small integer written as one character is smaller than the same value in a fixed-width eight-byte field. The compactness win comes from strings, repeated field names, punctuation and the ability to skip, not from every individual value. Second, whether a reader needs an external definition is a **separate axis** that merely correlates with this one — plenty of binary encodings describe themselves inline, and plenty of text messages are useless without a written contract. ## The cost is not only size Size is the part people quote, but decode work is often the part that bites. A text parser inspects characters one at a time to find where each value ends and then converts digit characters back into a number; a length-prefixed binary reader is told the width up front and can copy or skip without looking at the content. That is why compressing a text payload is not equivalent to going binary: it addresses the bytes on the link and leaves the processor cost on the receiver roughly where it was. ## Where the line falls in practice - **Low-volume, human-facing, or crossing an organisational boundary** — text almost always wins. The bytes cost nothing at that rate, and readability pays every time someone debugs it. - **A hot internal hop with large fan-out** — the arithmetic flips: the same message shape multiplied by a high rate makes size and decode cost real money, and the people debugging that hop can be given a decoder. - **Mixed, which is common** — a compact encoding on the hop plus a rendering step that turns captured messages back into characters for logs, traces and incident tooling. That buys most of the compactness without giving up inspectability where it is needed. ## How this is asked Interviewers are checking that you name the trade rather than recite a winner. - Name the axis first: inspectability against bytes and processor time. - Give the condition that decides it: the volume of the hop, and whether a human ever reads those bytes. - Avoid absolutes. A candidate who says binary is always better has not debugged a hop they could not read.
- Is a text encoding always larger than a binary one for the same values?No. A small integer written as one or two characters is smaller than the same value in a fixed-width eight-byte field. The compactness of a binary encoding comes from packed strings with lengths, numeric tags instead of spelled-out field names, no punctuation and the ability to skip. Across realistic messages it usually wins comfortably, but the claim is statistical, not universal.
- If readability is the point, why not keep text everywhere and simply compress it?That is often the right first move: a general-purpose compressor removes most of the redundancy of repeated field names and punctuation for very little engineering effort. What it does not remove is decode cost — the receiver still scans characters and re-parses numbers — and it does not make the compressed bytes readable either, so you keep readability only before compression and after decompression.
A parcel with a handwritten address label versus one carrying only a barcode. Both route correctly, but only one tells you where it is going when the scanner is unavailable.
saying these in an interview costs you the question
- Says binary is always smaller and faster, naming no case where text wins
- Treats text versus binary as the same axis as self-describing versus schema-driven
- Believes a readable payload needs no written contract because you can see the fields
- Cannot name anything operational that is lost when a hop stops being readable
- Assumes compression makes the choice irrelevant for both size and decode cost