Questions
4 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: 8/10
Core concepts
Kafka is the durable event backbone that decouples producers from consumers in time, space and scale
In an event-driven architecture, services publish facts about what happened (OrderPlaced, PaymentCaptured) and other services react. Kafka's role is to be the durable, ordered, replayable backbone that carries those facts. The producer does not know who consumes its events, so adding a new consumer such as a fraud or recommendation service requires no change to the producer. That is loose coupling. Because Kafka retains events, consumers can be down, slow or newly created and still catch up, which is temporal decoupling. Because processing is asynchronous, a spike in orders does not cascade into synchronous failures across services.
Replay is what separates this from plain messaging. A consumer with a bug can be fixed and rewound, a new read model can be rebuilt from history, and an audit trail comes almost for free. Keys give per-entity ordering, and consumer groups give horizontal scaling. Compacted topics let you keep the latest state per key, which supports data sharing and cache or read-model bootstrapping.
javascript
- 1
Trade-off: eventual consistency and harder debugging. A synchronous call is easier to trace and reason about, so I keep request/response for queries that need an immediate answer and use events for state changes other services care about.
- 2
Common mistake: the dual-write problem. Updating a database and publishing to Kafka as two separate steps can leave them inconsistent. Use the transactional outbox pattern with CDC, or a single source of truth.
- 3
Common mistake: assuming exactly-once end to end. At-least-once delivery is the realistic default, so consumers must be idempotent (dedupe on eventId). Kafka transactions give exactly-once only within a Kafka read-process-write pipeline.
- 4
Common mistake: treating events as commands or leaking internal DB schemas. Events should be stable, versioned contracts managed with a schema registry and compatibility rules.
- 5
Alternative: Kafka versus event sourcing. Kafka can be the event store, but many teams keep the system of record in a database and use Kafka for propagation. I pick event sourcing only when auditability and rebuildable state are core requirements.
- 6
Version note: idempotence is on by default in newer clients (3.0+), and KRaft replaces ZooKeeper in 4.0. Confirm what your platform runs.
Scenario Questions
0-2 years experience
- 1An order service needs to tell the inventory and shipping services that an order was placed. Describe how events on Kafka would let you add a third service later without touching the order service.
- 2What is the difference between an event such as OrderPlaced and a command such as PlaceOrder, and which would you put on a topic?
2-5 years experience
5-8 years experience
- 1A new analytics service needs to build its read model from all historical order events. How do you bootstrap it, keep it in sync afterwards, and ensure retention supports this?
- 2Two teams disagree on whether to use choreography (services react to events) or orchestration (a central coordinator) for an order saga. How would you decide?
8+ years experience
- 1Design the event contract governance for 40 services: ownership, naming, schema compatibility, deprecation and breaking changes. What would you standardize and what would you leave to teams?
- 2Leadership asks if Kafka should be the system of record for orders via event sourcing. Walk through the criteria, risks (schema evolution, compaction, GDPR deletion) and your recommendation.