Questions
1 of 5
Basics
Cluster Architecture
Topics, Partitions and Records
Producers
Consumers
Consumer Groups
Offset Management
Replication and Fault Tolerance
Storage Internals
Networking and Request Processing
Performance and Throughput
Delivery Semantics
Transactions
Kafka Streams
Kafka Connect
Schema and Serialization
Security
Error Handling and Retry Patterns
Ordering and Partitioning Design
Testing
Monitoring and Observability
Debugging and Troubleshooting
Deployment and Operations
Admin and CLI Operations
Reliability and Disaster Recovery
Integration Patterns
Modern Kafka Architecture
Advanced Internals
Scalability and Capacity Planning
Architecture and System Design
Production Best Practices
Expert Edge Cases
Versioning and Upgrades
Admin and CLI Operations
Senior End-to-End Scenarios
Difficulty: 2/10
Core concepts
Kafka is a distributed, durable commit log used as an event-streaming platform
Kafka is a distributed event-streaming platform built around a partitioned, replicated, append-only log. Producers append events to topics, brokers persist them to disk and replicate them across machines, and consumers read at their own pace by tracking an offset. The problem it solves is moving large volumes of events between systems reliably, in near real time, without every producer and consumer being wired to each other point to point. Before Kafka, teams ended up with N x M integrations, nightly batch ETL, or fragile queues that dropped data when a consumer was slow.
The key distinction from a simple message queue is that Kafka treats messages as a retained log, not a transient buffer. A classic queue deletes a message once it is acknowledged. Kafka keeps records for a configured retention period (or forever with compaction or infinite retention) regardless of whether anyone has read them. That means multiple independent consumer groups can read the same data, a new service can be added later and replay history, and a consumer bug can be fixed and reprocessed. Throughput comes from sequential disk I/O, batching, compression, zero-copy transfer and partitioning, which spreads load across brokers and consumers.
javascript
- 1
Trade-off: Kafka gives you throughput, durability and replay, but you pay with operational complexity, eventual consistency and no per-message routing or priority. If you only need simple task distribution, a plain queue is cheaper to run.
- 2
Common mistake: calling Kafka a message queue and expecting per-message acknowledgement, per-message TTL or global ordering. Ordering is guaranteed only within a partition.
- 3
Common mistake: assuming data disappears after consumption. Retention is time or size based and independent of consumers.
- 4
Version note: ZooKeeper was removed in Kafka 4.0, which runs only in KRaft mode. Older clusters and many tutorials still describe ZooKeeper-based setups, so state which version you are talking about.
- 5
Version note: Kafka is also gaining queue-like semantics through share groups (KIP-932). Check the maturity status in your release before relying on them.
Scenario Questions
0-2 years experience
- 1Your team has a web app that writes user sign-up events, and the email service, analytics service and fraud service all want those events. Explain how you would use a Kafka topic here and what each service would do.
- 2A colleague says Kafka deletes a message once the consumer has read it. Using a console consumer, how would you show them this is wrong?
2-5 years experience
- 1A nightly batch job copies data from an operational DB into a warehouse and the business now wants it in minutes. How would you introduce Kafka, and what would you do about the data already in the DB?
- 2A new service launches and needs the last 30 days of order events. What must be true about the topic configuration for this to be possible, and how does the service start from the right place?
5-8 years experience
- 1Eight teams currently integrate point to point over REST and a few ad hoc queues. You propose Kafka. What would you say to a skeptical engineering manager about cost, risk and migration order?
- 2An order topic is keyed by orderId and consumers show out-of-order processing for a single order. Walk through the places where ordering can be lost, from producer to consumer.
8+ years experience
- 1You are asked to define the organization's guidance on what counts as an event versus a command versus a query, and which of these belong on Kafka. What principles do you set and what do you refuse to support?
- 2A VP asks why not just use a managed queue service for everything, since it is cheaper per message. How would you decide, with numbers and failure scenarios, which workloads justify Kafka?