A parks department proposes putting live festival ticket checkout—inventory locks, payments, and immediate confirmations—on Hive tables in HDFS. What is the sound judgment?
Select an answer to reveal the explanation.
Short Explanation
Hive is a research library for big history books, not the cash register selling today's tickets. Live checkout needs an OLTP system with fast transactional semantics. Keep Hive for analytics after the sales land in the lake.
Full Explanation
Putting live festival ticket checkout—inventory locks, payments, and immediate confirmations—on Hive tables in HDFS should be rejected because Hive targets analytics over Hadoop data, not transactional checkout OLTP with locking and low-latency commits. Approving it because Hive is a drop-in replacement for every OLTP database misunderstands Hive’s analytical purpose. Approving it only if Kafka is deleted from the entire city network mixes unrelated concerns and still leaves Hive unfit for checkout. Rejecting it only because MapReduce cannot count keys under any design is wrong on both facts and rationale—MapReduce can count keys, and that is not why checkout fails on Hive. Exam caveat: Hive/HDFS analytics ≠ OLTP system of record for payments and inventory. Operational check: keep festival checkout on a transactional payment platform, land sales extracts to HDFS/Hive for after-action analytics, and document the SoR versus analytics boundary for parks IT. In municipal platform operations, record the rationale in the architecture decision record so future on-call staff know which pattern was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that monitoring, access paths, and recovery steps still match the documented design for agencies that depend on this platform.