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

TASK
Explain, in your own words, why this chapter's own benchmark result
(Redis loses to an in-process Map) is not actually an argument
against using Redis in the real deployment this course is building
toward. What does the in-process Map's own win depend on that a real
serverless deployment doesn't reliably provide?

SOLUTION

The in-process Map's own win in this chapter's benchmark depends on a
condition that was quietly true throughout the whole test, but that a
real production deployment can't actually guarantee: that the Map is
built exactly once, kept alive in memory, and reused by every single
lookup that follows. In the benchmark script, that's genuinely true --
one Node process builds the Map at the top of the script and every
one of the 200 timed lookups reuses that same warm object, so there's
no cost anywhere in the measured loop beyond the lookup itself.

A real Next.js API route deployed the way Chapter 7 covers doesn't
get to make that same assumption. Serverless function instances can
be started fresh per request, or after a period of inactivity, with
no memory carried over from whatever ran before -- so a Map built
once wouldn't necessarily still be sitting in memory by the time the
next real user's request arrives. Worse, even when an instance does
stay warm for a stretch, a real deployment typically runs multiple
instances behind a load balancer at once, each with its own separate
process and its own separate memory. A Map built inside instance A is
invisible to instance B -- there's no way for the second instance to
benefit from work the first one already did, since they don't share
any state at all.

Redis's own real advantage isn't that it's faster than a Map -- the
benchmark showed clearly that it isn't, by roughly three orders of
magnitude. Its advantage is that it's the one place in this whole
comparison that's genuinely shared and genuinely persistent across
however many separate, memory-isolated instances a real deployment
happens to be running at any given moment. A dictionary cached in
Redis by instance A's own first lookup is immediately available to
instance B's very next request, something no in-process Map, however
fast, can offer once there's more than one process involved. That's
exactly the real capability Redis's own documentation names directly
-- "persistent session storage across serverless functions" -- and
it's a genuinely different property than raw per-call speed, one the
benchmark's single-process test was never actually set up to measure
in the first place.

WHY THIS WORKS AS AN ANSWER
----------------------------
It correctly identifies that the Map's own win rests on a
single-warm-process assumption the benchmark itself satisfied but a
real multi-instance serverless deployment doesn't, and explains
Redis's real value as cross-instance persistence and sharing rather
than raw speed -- a genuinely different property the single-process
benchmark was never designed to test.