The same civic program keeps history in HDFS, user profiles in NoSQL, and finance marts in a warehouse. What architecture idea does this illustrate?
Select an answer to reveal the explanation.
Short Explanation
History, profiles, and finance marts are different jobs — so they get different shelves. That mix is polyglot persistence, not a failure to pick one holy format.
Full Explanation
Polyglot persistence selects storage technologies by access pattern: distributed files for deep history, NoSQL for flexible profiles, warehouses for governed finance marts. One civic program can host all three under a coherent architecture. Integration and governance glue the stores together without erasing their strengths.
Mandating every dataset live in exactly one file format forever fails by concept: polyglot exists because access patterns differ. Requiring NoSQL to replace HDFS and warehouses for all historical finance closes fails by concept: finance marts often need warehouse governance. Claiming serving layers are illegal when more than one store exists fails by concept: serving still presents views across stores.
Exam caveat: Polyglot persistence = multiple stores by access pattern inside one architecture—not single-format mandates, NoSQL-replaces-all, or bans on serving.
Operational check: Document why history, profiles, and finance each use their store, define integration keys, and verify serving can present a coherent civic view without forcing one format. Document residual risk for civic operators and revisit after the next production change window. Confirm owners, SLAs, and rollback criteria in the runbook before go-live.