Question presented to candidate: "We are building an event-driven backend: orders, payments, notifications, analytics. Some people want Kafka, some want SQS. How do you decide between them, and would you ever use both?"
What a strong answer should cover:
- The core difference in model: Kafka is a partitioned, replicated log that consumers read by offset and can re-read; SQS is a managed queue where each message is handed to one consumer, hidden by a visibility timeout, and deleted once processed
- What follows from that: Kafka gives replay, many independent consumer groups over the same data, and per-partition ordering, with parallelism capped by the partition count; SQS gives per-message retries, a dead-letter queue, elastic consumers and almost no operations, with ordering only in FIFO queues per message group
- Delivery: both are at-least-once in normal use, so consumers must be idempotent; SQS standard can also deliver out of order
- Current limits checked against the docs: SQS keeps messages at most 14 days and accepts payloads up to 1 MiB (raised from 256 KiB in August 2025); FIFO throughput depends on high-throughput mode and region; Kafka 4.0 (March 2025) runs without ZooKeeper, and Kafka 4.2 made share groups (queue-style consumption, KIP-932) production-ready
- A decision based on requirements (replay, fan-out, ordering, throughput, team and cloud), and the common hybrid: Kafka (or a managed Kafka) as the event backbone, SQS for task queues around it
Clarifying questions expected:
- Do several teams need to consume the same events independently, and do we ever need to replay history?
- What ordering is required, and at what granularity (per order, per user, global)?
- What is the peak throughput, and are we all-in on AWS with a small platform team?
Code / implementation expected: Optional — a small simulation of both consumption models (offsets and consumer groups vs visibility timeout, redelivery and DLQ); the example does exactly that.