Exercise 2: The Real Operational Cost, and Why "Important" Isn't Enough — Possible Solution
====================================================================

THE REAL OPERATIONAL COST
------------------------------
Per this chapter, "running a dedicated search engine means operating
an entirely separate distributed system — real infrastructure, real
operational expertise, and real ongoing complexity keeping two systems
in sync. The primary database remains the source of truth, per
search1-1's own warn-box, and the search index has to be kept up to
date from that source of truth — real, ongoing engineering work, not
a one-time setup cost." Choosing a dedicated search engine isn't a
one-time decision that's "done" once it's installed — it means a team
takes on responsibility for an entirely additional, genuinely
distributed system (with its own real cluster-management concerns, per
search1-8's own sharding/replication material), AND takes on the
ongoing engineering work of keeping that search index's own data
synchronized with whatever the real, authoritative primary database
contains, for as long as the system runs.

WHY "SEARCH IS IMPORTANT" ALONE DOESN'T JUSTIFY THIS COST
------------------------------
Per this chapter's own warn-box, "'important' doesn't automatically
mean 'requires a dedicated distributed system' — the actual
determining factor, per this chapter's own framework, is scale and
sophistication requirements, not importance alone." A feature being
important to a business is a statement about how much the business
CARES about that feature working well — it says nothing, by itself,
about whether that feature's actual technical requirements (scale,
faceting, relevance sophistication) genuinely exceed what postgres1-6's
own built-in full-text search can already provide. Per this chapter's
own earlier material, "a lot of genuinely important search features
are served perfectly well by postgres1-6's own built-in capability" —
importance and technical necessity are simply two different questions,
and conflating them leads to paying the real, ongoing operational cost
of a separate distributed system for a benefit postgres1-6 could have
delivered just as well, at a fraction of the operational burden.

THE PRACTICAL CONSEQUENCE OF GETTING THIS WRONG
------------------------------
A team that reaches for a dedicated search engine purely because
search "matters to the business," without actually checking whether
the specific scale/faceting/relevance-sophistication requirements this
chapter's own framework asks about are genuinely present, ends up
paying real, ongoing operational costs (per this chapter's own "Real
Operational Cost" section) — infrastructure, expertise, sync
engineering — for a capability that likely could have been served by
the primary database's own already-existing full-text search feature,
with none of that additional distributed-system burden.

WHY THIS WORKS AS AN ANSWER
------------------------------
It states the real operational cost precisely using the chapter's own
wording, and explains specifically why "importance" and "technical
necessity" are two distinct questions, tying the explanation to the
chapter's own warn-box and its own five-question framework.