Performance
Batching: multiple-choice review
Crux Multiple-choice synthesis across the batching unit — the fixed-cost model, the size/wait window, break-even math, backpressure policies, and production failure modes.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. None is a definition to recite — each mirrors a call you make under load: when to batch, how wide the window goes, and what breaks when the happy path ends.
Goal
Confirm you can connect the fixed-cost model, the two-trigger window, break-even math, and production failure modes — the synthesis the individual lessons built toward.
Quiz
Completed
A payment service writes one durable ledger row per transaction at ~30 writes/s; the SLA is 'durable before we return success.' A teammate proposes 50 ms COPY batches to cut DB load. What does a senior decide, and why?
Heads-up It optimizes a load nobody is paying: 30 writes/s is not a throughput problem. It buys headroom you don't need while breaking the SLA, since buffered rows aren't durable and vanish on crash.
Heads-up Worse: you've told the user the payment succeeded while it sits in a volatile buffer. That converts a latency problem into data loss plus a lie — exactly the failure the durability SLA forbids.
Heads-up A smaller window shrinks the latency tax but doesn't fix the two real problems: there's still no queue depth to amortize at 30 writes/s, and any buffered-but-unflushed window can still lose an acknowledged payment on crash.
Quiz
Completed
A batching system is configured with max-size only (no max-wait timer). Traffic drops overnight. What is the failure mode, and what does adding the timer fix?
Heads-up That is the max-wait-only failure under HIGH load. A size-only batcher can't overflow — it can only fail to flush. The timer protects latency, not size.
Heads-up Size-only batching still batches; items accumulate until the buffer fills. The defect is unbounded latency for the waiting items, not lost batching.
Heads-up Low load is exactly when size-only is dangerous: the buffer never fills, so the oldest item can sit for seconds. That's a latency bug, and it's worst precisely when the system looks idle.
Quiz
Completed
For 4 KB payloads where the fixed per-call cost is ~50 µs and per-KB transfer is ~40 µs, will a large batch give a big speedup?
Heads-up speedup → N only when fixed cost dominates (F > V·n). Here variable cost dominates, so there's almost no fixed overhead left to amortize.
Heads-up The reverse: larger payloads push you toward speedup → 1, because the fixed cost becomes a smaller fraction of total work. Batching tiny messages is the big win.
Heads-up Break-even is per item, not per batch. Once one item's variable cost exceeds the fixed cost, no batch size rescues you — fitting under batch.size is irrelevant.
Quiz
Completed
A Kafka cluster's brokers sit under 20% disk and network, yet producers can't push past a fraction of capacity. The producers run Kafka 3.x defaults. What's the first fix?
Heads-up More clients each sending tiny batches doesn't help — you multiply small requests instead of making each one larger. The fix is fatter batches, not more of them.
Heads-up Compression runs per batch; with linger.ms=0 batches stay tiny, so the codec has little repetition to exploit. Compression amplifies batching — it can't substitute for it.
Heads-up The brokers are bored at under 20% utilization — disk isn't the bottleneck. The producer that refuses to wait is, so faster broker disks change nothing.
Quiz
Completed
A Kafka consumer polls 500 records; record 47 throws on deserialization. The pipeline retries the whole batch on any error. Consumer lag climbs to millions and rises, but the consumer looks healthy. What's happening, and what's the fix?
Heads-up More consumers all hit the same poison record and stall identically. Lag is rising because the offset can't advance past record 47, not because of throughput.
Heads-up That discards 499 good records to drop one — data loss, which for orders or payments can be a compliance incident. Split-and-retry isolates the one bad item instead.
Heads-up Record 47 is structurally corrupt — more time doesn't make it parse. The problem is failure isolation, not timing.
Quiz
Completed
A broker enforces a wire-level max message size, yet a 1 MB compressed batch OOM-kills it (the CVE-2023-34455 class). What is the correct defense?
Heads-up The attack lives entirely below the wire limit: 1 MB compressed already passed it. Shrinking the wire cap doesn't bound the decompressed size, so it offers no protection.
Heads-up That throws away the throughput and storage gains compression buys, and isn't necessary — a post-decompression bound (the snappy-java 1.1.10.1 fix) closes the hole while keeping compression.
Heads-up Idempotency stops replay, a different attack. A decompression bomb needs no duplicate payload — it OOMs the broker during expansion, before any per-item logic runs.
Recap
Across the unit the through-line is one decision sequence: confirm the fixed cost dominates the variable cost, confirm there’s queue depth and latency slack to spend, then size the window — max-size for throughput, max-wait for latency, whichever fires first — to the largest value under your SLO. The break-even is per item at F = V·n. Production then turns every efficiency property into a failure multiplier: a poison item kills N (split-and-retry plus DLQ), a fast producer floods a queue (bound it, pick block/drop/spill on purpose), and a compressed batch is an opaque envelope you must validate post-decompression and per-item. The recurring senior trap is optimizing throughput nobody is paying for while breaking a latency or durability contract.