Why choose Kafka over a REST endpoint for ingestion

WHAT THIS TESTS The interviewer wants to know you understand the difference between synchronous request-response and an asynchronous durable log, and when the broker's guarantees actually matter.

A GOOD ANSWER COVERS The core reason is decoupling and buffering. With a REST endpoint, producers call the processing service synchronously, so if the consumer is slow, down, or being deployed, producers either block, time out, or drop events, and a traffic spike directly overwhelms the consumer. Kafka inserts a durable, append-only log between them: producers write at high throughput and move on, while consumers read at their own pace, so a spike becomes growing consumer lag rather than lost data or cascading failure. The log persists messages with a retention window, enabling replay after a bug fix and letting multiple independent consumer groups each read the full stream for different purposes. Partitions provide horizontal scale and per-key ordering. You should still mention the costs: operational complexity, only at-least-once delivery by default requiring idempotent consumers, and per-partition rather than global ordering.

COMMON WRONG ANSWERS Claiming REST is simpler and therefore better while ignoring data loss under load. Treating Kafka as a queue that deletes after read; it is a retained log. Forgetting that exactly-once needs deliberate effort and that ordering is only per partition.

LIKELY FOLLOW-UPS How does Kafka guarantee ordering? What is consumer lag and how do you monitor it? When would a simpler queue or even REST be the right call?

ONE CONCRETE EXAMPLE During a flash sale, order, inventory, and analytics services emit a burst of events. Writing to Kafka lets the inventory consumer fall behind by a few seconds without dropping anything, the analytics group reads the same stream independently, and after fixing a pricing bug the team replays the topic to recompute results.