Exercise 3: Why a Search Engine Usually Runs Alongside, Not Instead Of, a Primary Database — Possible Solution
====================================================================

THE CHAPTER'S OWN WARN-BOX
------------------------------
Per this chapter's own warn-box, "Elasticsearch/OpenSearch can store
and retrieve structured data, but it is not a general-purpose
replacement for a relational or document database — it doesn't offer
the same transactional/consistency guarantees mysql1, postgres1, or
mongodb1 do. In real practice, it's most commonly used alongside a
primary database — a 'search index' kept in sync from a genuine
source of truth — rather than as the sole system of record."

WHAT "THE SAME TRANSACTIONAL/CONSISTENCY GUARANTEES" WARNS AGAINST
ASSUMING
------------------------------
This directly warns against assuming Elasticsearch/OpenSearch behaves
like MySQL, Postgres, or MongoDB when it comes to things like real
ACID transactions, immediate strict consistency guarantees after a
write, or the same kind of rigorous data-integrity enforcement (unique
constraints, foreign-key-style referential integrity) those systems
provide by design. Just because Elasticsearch/OpenSearch CAN accept
and store JSON documents doesn't mean it was built to guarantee the
same correctness properties a genuine system-of-record database is
specifically designed to guarantee — this course's own chapter on
distribution (search1-8) will cover the real trade-offs Elasticsearch/
OpenSearch actually makes to achieve its own distributed-by-design
scale, trade-offs that a system prioritizing strict transactional
guarantees (like Postgres, per postgres1-9's own MVCC material) would
approach differently.

WHY IT'S COMMONLY USED ALONGSIDE A PRIMARY DATABASE, NOT INSTEAD OF ONE
------------------------------
Because Elasticsearch/OpenSearch doesn't offer the same guarantees a
genuine system of record needs, the common, real-world pattern keeps a
different database — one built specifically for those guarantees, like
Postgres or MongoDB — as the actual, authoritative source of truth for
an application's data. Elasticsearch/OpenSearch is then used as a
separate, purpose-built "search index," fed (kept in sync) FROM that
primary database, specifically to provide the fast, relevance-ranked
search and analytics capability the primary database either can't
provide at all, or (per postgres1-6) can only provide at a smaller
scale. If the search index itself were ever lost or became
inconsistent, the real, authoritative data would still be safe in the
primary database, and the search index could, in principle, be rebuilt
from that source of truth — a safety property that wouldn't exist if
Elasticsearch/OpenSearch were used as the SOLE system of record
instead.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains precisely what guarantees are being warned about
(transactional/consistency guarantees like ACID and strict
constraints), and explains the practical reasoning behind the
alongside-not-instead-of pattern — a primary database remains the
safety net a search-first system genuinely isn't designed to be.