Requirements & API: Apache Kafka

What an interviewer expects you to nail down before drawing a single box.

Functional

  • Accept events from producers and append them durably to a partitioned, ordered log per topic.
  • Let multiple independent consumer groups read the same topic at their own pace, tracking offsets per group.
  • Preserve ordering within a partition (all messages for a given key stay in sequence).
  • Support replay: a consumer can rewind to any retained offset and re-read.

Non-functional

  • Durability: an acked write (acks=all) must survive broker failure without loss.
  • High throughput: GB/sec aggregate ingest via sequential disk writes and batching.
  • Linear horizontal scalability: add partitions and brokers to grow throughput proportionally.
  • Availability under broker loss: automatic leader failover from the in-sync replica set within seconds.

API contract

produce(topic, key, value, acks=all) → { partition, offset }
Key determines partition (hash); acks=all waits for the full ISR.
subscribe(topic, group_id) → consumer
Joining a group triggers partition assignment / rebalance.
poll(timeout) → records[] then commit(offset)
At-least-once by default: commit after processing or risk reprocessing.

About Apache Kafka

Picture a busy product where one click can trigger a dozen things: a fraud check, an email, a search index update, a row in the analytics warehouse. If each of those services called the others directly, the whole thing would turn into a tangle that nobody can change safely. Kafka exists to untangle that. It teaches the single most reused pattern in backend systems: write events to a durable log once, then let many independent readers consume them at their own pace.

Here is the whole thing in plain steps. A producer publishes an event, hashing the message key to decide which partition it lands in, so every event for a given user stays in order. The event gets appended to a partition's log on a leader broker, which then replicates it to follower brokers. With acks=all the producer isn't told the write succeeded until every in-sync replica has it on disk, which is what lets the data survive a broker dying. On the read side, a consumer group splits the partitions across its members, and each member tracks its own offset so it knows where to resume.

The one idea worth getting straight is the offset. Think of a partition as a numbered list of events that only ever grows, and the offset as a bookmark each reader keeps. Kafka doesn't delete a message when you read it. It just hands you the next line and lets you move your own bookmark. That is why a second team can come along later, start a brand new group, set their bookmark to the beginning, and replay the entire history without affecting anyone else.

That single design choice is why one topic can feed billing, analytics, and a search indexer as three separate groups, each failing and recovering on its own. The tradeoffs are real: delivery is at-least-once by default, so consumers must be idempotent, and partition count quietly caps how much parallelism any one group can have. This system teaches partitioning as the scaling primitive, leader/follower replication and the in-sync replica set for durability, consumer groups and offsets, and why an append-only log makes Kafka a central event bus rather than just another queue.