A county wants one platform tuned for both high-volume permit transactions and heavy cross-year analytics. Which architecture stance is most sound?
Select an answer to reveal the explanation.
Short Explanation
Think of the checkout lane versus the research library. Checkout needs fast, careful writes; the library needs browsing and joins across history. Operational systems and analytic estates optimize for different jobs, so architecture treats those concerns separately.
Full Explanation
High-volume permit transactions and heavy cross-year analytics pull storage and access patterns in different directions. Sound architecture optimizes operational systems for transactions while shaping analytic estates for query patterns, rather than forcing one physical design to excel at both. Assuming one OLTP schema can always absorb enterprise analytic workloads without pattern changes invites lock contention and performance collapse for clerks. Placing analytic query patterns only inside the transaction log misunderstands both logging and analytics. Requiring warehouse dimensional models to replace every operational table of record confuses analytic presentation with systems of record. Exam stance: separate concerns by workload. Caveat: near-real-time operational reporting may use ODS or replication patterns, but that is still a deliberate separation from the primary OLTP write path. Operationally, measure permit OLTP latency under analytic load, design an analytic path for cross-year queries, and confirm clerk transactions remain within SLA when dashboards run. Benchmark clerk transaction latency and analytic query runtimes separately after isolation so both civic workloads meet their own success criteria.