How the interviewer opens it
“Design a distributed message log like Kafka. Producers append events to topics, and independent consumer groups read those events in order at their own pace, without losing accepted events when brokers fail.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- Product boundary and deployment
- Scale
- Read:write mix
- Latency and recovery
- Durability and availability
- Ordering
- Consumer groups and delivery
- Retention and slow consumers
- Scope exclusions
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Append events to topics and read them in partition order.
- Support independent consumer groups with durable progress and replay.
- Preserve acknowledged events through broker failure and elect replacement leaders safely.
- Retain events for a fixed window, independently of consumer progress.
Usually out of scope
- Stream-processing operators, joins, and query execution.
- Cross-partition transactions and end-to-end exactly-once processing.
- Cross-region replication and disaster recovery.
- Building an authentication or billing system.
What interviewers probe
- What an acknowledgment means during failover
- A leader can accept data that its replacement does not have. Replication count alone does not establish which records are committed or which replica may safely become leader.
- Partition ordering versus scaling a hot key
- Partitions supply both order and parallelism. Adding brokers or consumers cannot split a single ordered stream, and changing partition routing can break the ordering clients depend on.
- Consumer progress through crashes and rebalances
- Reading a record, completing its side effect, and committing an offset are separate actions. Reassignment also leaves a window where an old consumer may still be running.
- Retention, replay, and shared disk bandwidth
- The log must support fast appends, many readers, and old-data replay on the same storage. Slow groups cannot be allowed to create unbounded storage obligations or consume all broker resources.
Common mistakes
- Designing a stream-computation engine instead of the durable log and consumer substrate.
- Treating replication factor three as proof of durability without defining acknowledgments, safe elections, and fencing.
- Confusing partition order with global topic order or event-time order.
- Treating consumer groups as destructive queues or claiming offsets alone provide exactly-once side effects.
- Using partition-count changes or extra consumers as a transparent fix for a hot ordered key.
- Ignoring retained storage, replay traffic, replica catch-up, and disk headroom.
The bar by level
- Senior (L5/E5)
- Defines the acknowledgment and consumer-visibility boundaries, gives a safe leader-failover story, and handles ambiguous retries. Designs durable group offsets, rebalance generations, segmented storage, retention, and bounded replay. Uses the workload estimates to distinguish aggregate capacity from a hot partition's limit.
- Staff (L6+/E6+)
- States and defends the committed-prefix invariant through network splits, replica membership changes, stale leader recovery, and coordinator failure. Separates assignment fencing from external side-effect correctness. Identifies ordering-sensitive partition migrations, control-plane recovery, replay and replica-rebuild capacity, and the precise availability sacrificed to preserve acknowledged data.