A municipal payment portal must raise a fraud flag within a fraction of a second on each card authorization. Why is overnight MapReduce a poor primary design?
Select an answer to reveal the explanation.
Short Explanation
Fraud flags are like a bouncer checking IDs at the door—decision now, not tomorrow morning. Overnight MapReduce jobs finish too late for per-authorization latency. Streaming or online scorers handle that race; MR still helps for nightly forensics.
Full Explanation
A municipal payment portal that must raise a fraud flag within a fraction of a second on each card authorization should not use overnight MapReduce as the primary design because classic MapReduce is batch-oriented and cannot meet ultra-low-latency per-event response needs. It is false that MapReduce cannot read files stored in HDFS under any circumstances. It is false that MapReduce permanently forbids counting or grouping keys—that is core MapReduce work in batch. It is false that MapReduce only runs on a single laptop CPU with no cluster option. Exam caveat: match latency shape to paradigm—batch MapReduce ≠ synchronous authorization path. Operational check: implement fraud checks on the online payment path with appropriate streaming or rules services, and use MapReduce only for offline model training or retrospective fraud analytics. 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.