A high-volume internal hop uses a text encoding and the team wants a binary one purely for size — what do you check first?

## First, establish what the hop is bound by A request to change encodings for size is a proposed solution, not a problem statement. The questions that decide it: - **What saturates first?** Link capacity, receiver processor time, or latency at the tail. Each points at a different fix. - **What is the target?** A number and a deadline, otherwise there is no way to tell whether a cheaper move suffices. - **What is the traffic shape?** Rate multiplied by average message size, and how much of the message any single consumer actually reads. - **Who reads these bytes today?** On-call engineers, a support workflow, a replay tool, a partner. That list is the bill for going opaque. ## Compression is the cheap middle move A text payload is dominated by exactly what a general-purpose compressor handles best: field names repeated on every record, punctuation, whitespace, and values drawn from a small set. Applying a compressor at the boundary keeps the encoding, keeps the contract, keeps both sides' code, and keeps the message readable everywhere it is not in flight. | Constraint | Compress the text | Move to a compact binary encoding | | --- | --- | --- | | Link capacity | Addresses it directly | Addresses it directly | | Receiver decode cost | Makes it slightly worse | Addresses it directly | | Cost of fields a consumer ignores | Unchanged | Largely removed by skipping | | Inspectability | Preserved outside the wire | Lost without tooling | | Cost to change | Small and reversible | A coordinated change on both sides | Compression is not free: it spends processor time on both ends, and on a hop already short of it, that makes things worse rather than better. That is the case where the answer is genuinely the encoding. ## What a binary encoding buys that compression does not 1. **Decode cost.** The receiver reads sized fields instead of discovering boundaries character by character, and compression cannot touch that. 2. **Skipping.** A consumer that wants three fields out of forty advances past the rest by their stored lengths rather than scanning them. 3. **Steadier latency.** No compress-and-decompress step sitting on the critical path of each message. ## What you give up, and who pays - The captured message stops being self-explanatory; understanding it now requires a decoder that matches the definitions in force. - Ad-hoc tooling built around characters — searches, filters, replay scripts — stops working. - The cost is paid by whoever is on call at two in the morning, which is usually not the team proposing the change. - The change must land on both sides, so there is a window in which readers and writers disagree unless it is sequenced deliberately. None of these is a veto. They are the other half of the ledger, and a proposal that does not mention them has not been thought through. ## A defensible plan 1. Measure the hop: rate, message size, link headroom, receiver processor headroom, and which fields consumers actually read. 2. Turn on compression first if the link is the constraint and processor headroom exists; re-measure. 3. If decode cost or the ignored-field tax is the constraint, propose the compact encoding, with a named owner for the decoder that incident tooling will need. 4. Keep a readable rendering in the logging and tracing path, so the bytes that people read stay characters even when the bytes that travel are not. 5. Re-measure after the change and state plainly whether the original target was met. ## How this is graded Interviewers are watching whether you optimise the measured constraint or the one that was handed to you. A strong answer names the binding resource, offers the cheaper move first, states clearly what compression does not fix, and prices the loss of inspectability in terms of the people who will pay it. A weak answer starts migrating encodings before anyone has said what saturates.