A city operations center needs Kafka-compatible streaming so several existing consumer apps can share the same topics, while a separate telemetry lane only needs an AWS-native stream. How should the architect choose?
Select an answer to reveal the explanation.
Short Explanation
Think of MSK as renting a Kafka neighborhood the city’s existing consumer apps already know how to walk. Kinesis is the AWS-native stream when you don’t need that Kafka handshake.
Full Explanation
Choosing Amazon MSK for Kafka-compatible city operations consumers and Amazon Kinesis Data Streams for an AWS-native telemetry lane matches how municipal streaming workloads actually split. MSK works because it presents Apache Kafka protocol and topic semantics that existing consumer applications already understand, so several permit, CAD, or operations apps can share the same topics without rewriting client libraries. Kinesis Data Streams works for the separate telemetry lane because that path only needs a managed AWS-native stream API, shard scaling, and consumers built for Kinesis—not Kafka broker compatibility. The architect’s decision is therefore ecosystem-driven: keep Kafka where the city’s invested consumer estate requires it, and use Kinesis where greenfield AWS-native streaming is enough.
Using Kinesis for the Kafka-compatible consumers and MSK for the AWS-native lane fails by concept because it inverts the compatibility requirement: Kinesis does not speak the Kafka protocol that those existing apps need, and forcing MSK onto a lane that only wants an AWS-native API adds Kafka operational surface without benefit. Replacing both lanes with a single Amazon SQS queue and Lambda polling fails because SQS is a discrete message queue, not a continuous multi-consumer log with Kafka/Kinesis-style fan-out of streaming topics for several independent consumer apps sharing offsets or shards. Assuming Amazon MQ for ActiveMQ is the Kafka-compatible bus fails because Amazon MQ centers on ActiveMQ/RabbitMQ protocols; it is not a native Kafka protocol service for multi-consumer Kafka ecosystems.
Exam caveat: MSK still requires capacity, networking, and consumer-group planning; “Kafka-compatible” does not erase the need for topic ACLs, monitoring, and upgrade discipline. Operational check: inventory which municipal apps already use Kafka clients versus AWS SDKs, document which lane each topic belongs to, and validate a smoke test where Kafka consumers read MSK topics while the telemetry lane uses Kinesis APIs without cross-wiring credentials or endpoints.