The architecture board maps ingestion, processing, storage, and serving layers before choosing Hadoop, MapReduce, NoSQL, Spark, or Kafka components. Why is that sequencing sound?
Select an answer to reveal the explanation.
Short Explanation
Draw the rooms before you buy the furniture. Layers and patterns tell you what Hadoop, Spark, or Kafka are for—not the other way around.
Full Explanation
Mapping ingestion, processing, storage, and serving layers before selecting Hadoop, MapReduce, NoSQL, Spark, or Kafka is sound because architecture patterns frame the civic problem so technology choices fill each layer deliberately. Layers answer what capability the city needs; tools answer how that capability will be implemented without confusing brand names for design. Selecting vendor logos first so layers can be invented afterward produces tool-driven sprawl without clear SLAs, owners, or failure domains. Claiming municipal platforms never need layers if a single laptop holds all files denies scale, resilience, multi-consumer, and governance realities of city data. Assuming tool names alone guarantee correct SLAs without an architectural model confuses branding with engineering discipline. Exam caveat: BDPC sequences conceptual architecture ahead of ecosystem component deep-dives—pattern first, product second. Operational check: for a new mobility initiative, complete a one-page layer diagram with owners and SLAs, then map candidate tools into those layers in an architecture decision record before procurement or cluster builds begin, and revisit the diagram when requirements change.