System Design · Guide

Apache Kafka

Topics, partitions, consumer groups, event streaming.

— min read System Design

Theory

Apache Kafka: Topics, partitions, consumer groups, event streaming.

Apache Kafka is a distributed commit log for event streaming. Producers append records to topic partitions; consumers read at their own offset — enabling replay, multiple independent consumer groups, and decoupled event-driven architectures.

Topics are split into partitions for parallelism. Records with the same key land on the same partition, preserving per-key ordering. Increase partitions to scale consumers — one consumer per partition within a group.

Consumer groups coordinate partition assignment — rebalancing on member join/leave. Commit offsets after processing for at-least-once delivery. Retention policies (time or size) bound storage; compacted topics keep only the latest value per key for changelog streams.

Production rollouts require idempotent automation, peer review, staged apply, and documented rollback — treat changes as production code.

Interviewers want STAR stories linking Apache Kafka to measurable outcomes: fewer outages, faster deploys, lower cost, or reduced toil.

Architecture Diagram

Users / clients
         |
  Apache Kafka
         |
  Core services
         |
  Data + observability

Examples

bash
# Apache Kafka
# Topics, partitions, consumer groups, event streaming.
# Validate in staging before production rollout.

Interview Questions

What problem does Apache Kafka solve?

It addresses the core use case described in production architecture — map features to reliability, scale, or velocity outcomes.

Key components of Apache Kafka?

Identify inputs, outputs, control plane, data plane, and failure domains — interviewers want structured decomposition.

Common production pitfalls?

Misconfiguration, missing observability, no rollback path, and scaling bottlenecks under peak load.

How do you test changes safely?

Staging parity, canary/gradual rollout, automated health checks, and documented rollback.

Metrics to prove success?

Error rate, latency percentiles, throughput, cost, and toil reduction — pick one primary SLO.

Beginner vs advanced concern?

Beginners focus on setup; advanced teams focus on blast radius, security boundaries, and operability at 10× scale.

Best Practices

  • Treat Apache Kafka config as code with review and CI validation.
  • Define SLOs and dashboards before production cutover.
  • Document rollback and ownership for on-call.
  • Use least privilege for credentials.

Common Mistakes

  • Adopting Apache Kafka without measurable success criteria.
  • No staging environment mirroring production constraints.
  • Missing rollback path during incidents.
  • Undocumented on-call expectations.

Trade-off Analysis

Apache Kafka improves topics, partitions, consumer groups, event streaming. but adds operational and cognitive complexity — justify with load and team size.

Favor simplicity until metrics (p99 latency, error rate, cost) prove the pattern necessary.

Every redundancy layer trades capital/operational cost for availability — align with explicit SLO targets.

Document accepted inconsistency windows and recovery behavior before production cutover.

Cheat Sheet

ApacheTopics, partitions, consumer groups, event streaming.
SLOService level objective
RollbackRevert to last known good
CanaryLimited blast-radius rollout
RunbookIncident steps

Practical Exercises

Apache Kafka sandbox

Stand up Apache Kafka locally or in free tier; document commands and failure recovery.

Failure drill

Introduce misconfiguration; practice detection and rollback under time limit.