Exercise 3: Why a 30-Second, 4GB-Loading Service Is a Poor Fit — Possible Solution
====================================================================

Explanation:

Per this chapter's own "honest limitation" section, socket activation
"trades 'always consuming resources' for 'occasionally slower first
response'... a genuine tradeoff, not a pure, unconditional win." The
chapter is explicit that this tradeoff specifically hurts "a service
with genuine startup latency -- loading a large dataset, warming a
cache" -- which is exactly what this service does, loading a 4GB
dataset into memory on startup, taking roughly 30 seconds to do so.

If this service were socket-activated, per the chapter's own
compare-table, every first connection arriving after any idle period
would have to wait for the FULL 30-second startup process to complete
before the service could actually begin handling that request --
the connection itself would be accepted immediately at the socket
level (per Exercise 2's own material), but the actual response would
be stuck behind a genuinely long, real delay while the 4GB dataset
loads. A 30-second wait for a single request is a severe, almost
certainly unacceptable latency spike for whoever happens to trigger
that first post-idle connection -- a dramatically worse experience
than the "occasionally slower" framing might suggest for a
lighter-weight service.

An always-running version of this same service would only ever pay
that 30-second cost once, at boot, rather than repeatedly every time
the service happens to go idle and then receive a new connection --
making the resource-savings argument for socket activation a poor
trade here specifically because the startup cost is so large and the
service is apparently used often enough to go idle and restart
repeatedly.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly applies the chapter's own named limitation (real
startup latency services are a poor fit) to the specific 30-second/4GB
numbers given in the exercise, explaining the concrete, severe
consequence (a 30-second latency spike on the triggering request)
rather than a generic "it would be slower."