One city Kafka topic must refresh a low-latency NoSQL hot store and also land long-term copies in HDFS. Which architecture idea applies?
Select an answer to reveal the explanation.
Short Explanation
One announcement, two listeners—hot NoSQL for now, HDFS for the archive. Fan-out from a single topic beats making producers shout twice. Same event, different homes.
Full Explanation
One municipal Kafka topic can fan out to separate consumers—one refreshing a low-latency NoSQL hot store and another landing long-term copies in HDFS—without forcing a single sink to serve both latency and lake goals. Independent consumer groups read the same events and apply sink-specific semantics, which is a core bus architecture idea for civic platforms. That separation keeps hot-path and cold-path requirements from collapsing into one brittle pipeline.
Forcing the NoSQL cluster to poll HDFS every hour reintroduces batch delay and makes the hot store depend on lake landing success. Duplicating every producer so each destination gets a privately authored stream multiplies producer complexity and drift risk instead of using the bus as a shared contract. Storing events only in broker memory and never landing them elsewhere abandons durability for analytics and recovery.
Exam caveat: fan-out consumers still need their own lag monitoring, idempotent writes, and schema compatibility; a healthy topic does not guarantee every sink is healthy. Operational check: publish a test event and confirm it appears both in the NoSQL hot key and in the lake landing path, then induce lag on one consumer and verify the other continues independently.