Notes on Building Event-Driven Systems with Kafka

This is a placeholder post — replace it with your own write-up.

When a system needs to fan work out to multiple consumers without them stepping on each other, an event-driven architecture built on Kafka is a natural fit. A few things matter more than they first appear to:

Partitioning is the whole game

Ordering guarantees in Kafka only hold within a partition, not across a topic. Picking a partition key that matches your actual ordering requirement (e.g. a customer ID or entity ID) is the single most important design decision — get it wrong and you'll see subtle bugs where events for the same entity arrive out of order.

Idempotency is not optional

Consumers will see duplicate messages eventually — that's the trade-off for at-least-once delivery. Designing handlers to be idempotent from day one is much cheaper than retrofitting it after a duplicate-processing incident.

Replacing a system that can't scale

Migrating from a request/response system to an event-driven pipeline usually isn't a rewrite — it's a gradual strangler-fig migration: introduce the event bus alongside the old system, dual-write, verify parity, then cut over consumers one at a time.

old system --> (dual write) --> event bus --> new consumers
                              \-> old consumers (until cutover)

More to come as I write this up properly.