Romaji to Kana Converter: React & Next.js — Chapter 6, Exercise 2
=====================================================================

TASK
This chapter's own MGET test batched 200 keys into a single round
trip. Real production sentences would realistically need far fewer
lookups per request -- closer to 5-15 kanji-eligible substrings per
sentence. Re-run the individual-GET-vs-MGET comparison at a more
realistic batch size of 10 keys, and explain whether the speedup
still matters at that smaller scale.

SOLUTION

Re-running the same real comparison, this time with only 10 keys
instead of 200:

  10 individual GETs total: 7,963.5 us  (796.35 us/call)
  1 MGET for all 10 keys:     800.7 us  total
  speedup: 9.9x

The speedup is real and still substantial, but it's meaningfully
smaller than the 84x measured for 200 keys -- and that difference
follows directly from how the two approaches actually scale.
Individual GETs cost roughly (number of keys) x (one round trip),
so their total grows linearly with the batch size. A single MGET
costs roughly one round trip plus a small, genuinely tiny marginal
cost per extra key riding along in the same request -- so its own
total barely grows at all as more keys are added. The ratio between
the two is therefore roughly bounded by the batch size itself: you
can't collapse 10 round trips into something more than 10x faster,
since there's no way to save more round trips than you started with.
That's exactly what shows up in the numbers -- ~9.9x for a 10-key
batch versus ~84x for a 200-key batch, both consistent with "the
speedup tracks how many round trips got merged into one."

Does the ~10x speedup still matter at a realistic 10-key sentence
size? Yes, concretely. The individual-GET version costs roughly
7,964us -- nearly 8 full milliseconds -- just in round-trip overhead
for one sentence's worth of kanji lookups, a real, user-visible delay
on its own. The batched version does the same job in roughly 801us,
under a millisecond. Given Chapter 4's own finding that a single
network round trip already costs roughly 14ms end to end for the
existing kana-only route, adding an unbatched 8ms of Redis round
trips on top of a future kanji-aware route would very plausibly
double its total response time. Batching removes essentially all of
that extra cost for the price of one line of code (redis.mget(...)
instead of a loop of redis.get() calls), which makes it worth doing
even at this smaller, more realistic scale.

WHY THIS WORKS AS AN ANSWER
----------------------------
It re-measures the real comparison at the smaller, realistic batch
size rather than assuming the 84x figure holds at any scale, explains
why the speedup itself is proportional to batch size (individual
calls scale linearly, one MGET barely scales at all), and connects
the resulting absolute time saved back to Chapter 4's own real
14ms-round-trip finding to judge whether it's actually worth doing.