Exercise 2: "Distributed by Design From Day One" vs. Sharding/Replication Added Later — Possible Solution
====================================================================

WHAT "DISTRIBUTED BY DESIGN FROM DAY ONE" MEANS
------------------------------
Per this chapter, "Elasticsearch and OpenSearch were built distributed
from the very beginning: running a 'cluster' of one or more nodes is
the normal way to run either engine even in development, with sharding
and replication as foundational architectural concepts baked into the
core design from day one, not layered onto a single-node-first
architecture afterward." Even a single developer running Elasticsearch
or OpenSearch on their own laptop for local testing is still running
it as a "cluster" (just a cluster of one node) — the entire system's
own internal architecture assumes and is built around the concept of
multiple nodes, sharding, and replication as basic, load-bearing
concepts from the very first line of its own design, not an
afterthought.

HOW THIS CONTRASTS WITH MONGODB2-6'S OWN SHARDING
------------------------------
Per this chapter, "postgres1-11's own replication and mongodb2-6's own
sharding are both real, mature capabilities — but both were added to
engines whose original design center was a single-node system, later
extended to support multiple nodes." MongoDB's own core document model
and query engine were originally designed and usable as a genuine,
complete single-node system; sharding was later added as a real,
substantial capability layered on top of that already-existing
single-node foundation to allow it to scale across multiple machines
when needed — but a MongoDB deployment doesn't NEED to be sharded at
all to be a complete, working system.

HOW THIS CONTRASTS WITH POSTGRES1-11'S OWN REPLICATION
------------------------------
The same applies to Postgres: its own relational engine, transaction
model, and query planner were designed and are fully usable as a
complete single-node system, with streaming/logical replication (per
postgres1-11) added specifically to extend that already-complete
single-node design to multiple nodes for high availability or read
scaling — again, a genuine, real capability, but one built ON TOP OF
an originally single-node-centered architecture, not present as a
basic assumption from the system's own earliest design.

THE CORE DIFFERENCE
------------------------------
In both MongoDB and Postgres, a fully functional single-node
deployment is the DEFAULT, unremarkable case, with distribution as an
optional additional capability layered on when genuinely needed. In
Elasticsearch/OpenSearch, per this chapter, a "cluster" (even of one
node) is simply how the system is normally run at all — distribution
isn't an optional add-on layered onto an otherwise-complete single-node
design, it's baked into the system's own foundational architecture
from the very beginning.

WHY THIS WORKS AS AN ANSWER
------------------------------
It defines "distributed by design" precisely using the chapter's own
wording, and explains the specific architectural difference (default
single-node completeness with distribution as an optional layer, vs.
distribution as a foundational assumption from the start) for both
named comparison points individually.