A city lake holds the same mobility and permitting facts, but council packets need polished PDF summaries while dispatch consoles need sub-second lookups. Which architectural idea best explains serving both consumers from one platform?
Select an answer to reveal the explanation.
Short Explanation
Think of the lake as a kitchen pantry: chefs and catering trays both pull ingredients, but plating differs. Same facts can power slow, pretty council packets and snappy dispatcher lookups through different serving paths.
Full Explanation
A municipal lake can hold one curated set of mobility and permitting facts while still supporting consumers with incompatible latency and format needs. The sound architectural idea is that a shared analytical store feeds multiple serving paths—batch PDF generation for council packets and low-latency keyed APIs or caches for dispatch consoles—each tuned to its SLA without cloning the raw lake. Requiring every consumer to read only through a single nightly warehouse snapshot with identical SLAs collapses those differences and forces dispatchers to wait on council-report timing. Giving council PDFs and dispatcher APIs each a separate raw lake duplicates ingestion, governance, and cost while inviting drift between 'the same' facts. Claiming serving differences disappear if everyone queries HDFS blocks with the same MapReduce job confuses storage access with serving characteristics; MapReduce batch scans are not a sub-second console path. Exam caveat: shared storage plus specialized serving is not the same as a single physical store with one access pattern—architecture separates concerns. Operational check: trace one mobility fact from curated lake tables into both the PDF pipeline and the dispatch lookup service, confirm ownership and freshness SLAs differ by path, and document those paths in the city architecture register so emergency operations and clerks know which interface to trust.