Questions
3 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: 5/10
Core concepts
Kafka is a poor fit for synchronous request/response, small low-volume workloads, ad hoc querying, and per-message routing or priority needs
Kafka solves a specific problem: high-throughput, durable, replayable streams between many producers and consumers. When that problem is not yours, you pay its costs (cluster operations, partition planning, eventual consistency, schema governance, consumer-lag monitoring) for little benefit. The question I ask first is: does anyone need to replay this data, or do multiple independent systems need it? If the answer is no for both, I look elsewhere.
- 1
Synchronous request/response: when a caller needs an immediate answer (login, price lookup, payment authorization), use HTTP or gRPC. Faking request/response over Kafka with reply topics and correlation IDs adds latency and complexity.
- 2
Small scale: a few hundred messages per hour between two services rarely justifies a cluster. A managed queue or even a database table is simpler and cheaper.
- 3
Ad hoc querying and system of record: Kafka is not a database. There is no secondary indexing or flexible querying, and reading a key means scanning or keeping a materialized view. Use a database, or Kafka Streams or ksqlDB state stores only for derived views.
- 4
Complex routing, per-message priority, per-message TTL or delayed delivery: these belong in a broker like RabbitMQ or a cloud queue. Kafka consumers process in offset order, so one slow or poison message blocks that partition unless you build retry topics.
- 5
Large payloads: Kafka's default max message size is about 1 MB, and large records hurt throughput and memory. Store the blob in object storage and send a reference.
- 6
Strict global ordering: ordering is per partition only. A single-partition topic gives total order but removes scalability.
- 7
Tiny team without operational capacity: self-managing Kafka is real work. A managed service reduces this, but you still own topic design, schemas and lag alerting.
- 8
Version note: queue-like consumption through share groups (KIP-932) is evolving, so the 'Kafka cannot do queues' argument may weaken over time. Verify the status for your Kafka version.
The common mistakes are choosing Kafka because it is popular, using it as a database, and using it for transactional request/response. A good counter-example: a startup with one monolith and a background email job does not need Kafka. A database-backed job table or a managed queue gets them to production sooner. The right decision is the simplest tool that meets the durability, throughput and replay requirements you actually have.
Scenario Questions
0-2 years experience
2-5 years experience
5-8 years experience
- 1A single poison message keeps blocking a partition and lag grows. Explain why Kafka behaves this way and what pattern you would apply, or whether a different broker would have been a better choice.
- 2Product wants to push 20 MB scanned documents through the same topics as order events. Argue for or against and propose an alternative.
8+ years experience
- 1Several teams adopted Kafka for workloads where a database or queue would do, and cluster cost is rising. How do you assess which workloads to move off, and how do you set guardrails going forward?
- 2A business-critical flow needs strict global ordering across all customers and high throughput. Show how you would analyze whether Kafka can support this and what you would recommend.