Exercise 2: Why Multi-Server Write Concurrency Is the Clearest Disqualifier — Possible Solution
====================================================================

WHAT SQLITE1-4 ESTABLISHED
------------------------------
Per sqlite1-4, "SQLite's own locking, traditional or WAL, exists to
let a small number of processes or threads sharing one local file
coordinate safely," and critically, even WAL mode "still allows only
one writer at a time... it does not add support for multiple
simultaneous writers." This limitation is fundamental to how SQLite's
own file-level locking mechanism works — it isn't a configuration
option or something a newer SQLite version has since relaxed; it's a
structural property of the locking approach itself, present in every
mode covered in this course.

WHY THIS MAKES MULTI-SERVER WRITE CONCURRENCY THE CLEAREST
DISQUALIFIER
------------------------------
Per this chapter, this is named as "the single clearest,
least-debatable case" where SQLite is not the right choice. Unlike
some of the other "not a fit" categories this chapter names (database-
level access control, large distributed analytics), which are more
about SQLite lacking a FEATURE it could theoretically grow to support,
the single-writer limitation is a direct, structural CONSEQUENCE of
SQLite's own file-locking mechanism, covered in full in sqlite1-4.
There's no configuration flag, PRAGMA setting, or workaround within
SQLite's own core design that removes this constraint — it's not a
missing feature, it's the direct result of how SQLite coordinates
access to a single local file at all. Multiple separate SERVERS,
potentially in different locations, all needing to write to the exact
same SQLite file simultaneously, would have no way to safely coordinate
that access through SQLite's own locking mechanism, which per
sqlite1-4 assumes local, same-machine file access to begin with.

WHY THIS IS "LEAST DEBATABLE" COMPARED TO SQLITE'S OTHER LIMITATIONS
------------------------------
Other limitations this chapter names (e.g. lacking database-level
per-user access control) could conceivably be worked around at the
application level, or might simply not matter for a given use case
depending on its own specific requirements — there's room for
reasonable disagreement about how much they matter in a given
scenario. The multi-server write concurrency limitation offers no such
room: it's a direct, unavoidable consequence of SQLite's own core
architecture (per sqlite1-4), not a matter of degree or workaround.
If a real application genuinely needs multiple separate servers
writing concurrently, SQLite structurally cannot support that,
regardless of configuration or workaround — which is exactly why this
chapter treats it as the clearest, least-debatable disqualifying case.

WHY THIS WORKS AS AN ANSWER
------------------------------
It traces this chapter's own "clearest, least-debatable" claim
directly back to sqlite1-4's own structural explanation of why the
single-writer limitation exists, and explains why this particular
limitation admits less room for reasonable disagreement than the
chapter's other named limitations.