Kafka event-driven architecture explained

Events describe something that happened

An event-driven design lets one service publish a fact while other services react independently. For an order workflow, an order-created event can trigger fulfilment and notifications without requiring the API to synchronously call each downstream service. This reduces direct runtime coupling, but introduces lag, duplicate processing and schema coordination that must be designed deliberately.

The starter shows an order API, transactional storage, an event topic, separate fulfilment and notification consumers, and a dead-letter destination. The arrow from API to topic is labelled with a consistency strategy because a diagram must not imply that a database write and a Kafka publish automatically form one atomic operation.

Topics, partitions and independent consumers

A topic is divided into partitions. Record order is scoped to a partition rather than the entire topic. Choose a key such as order ID when related events need a consistent partition, and evaluate whether uneven key traffic could create a hotspot. More partitions can support more parallel work, but they are not a substitute for measuring bottlenecks.

Consumer groups let different applications read the same stream independently. Fulfilment and notifications therefore use separate groups. Within a conventional consumer group, partition assignment distributes processing among consumers; adding workers beyond the useful partition parallelism does not automatically increase throughput. Include group names and event contracts in the diagram so readers can tell broadcast consumption from shared work.

Make database and publication consistency explicit

A process can commit an order and fail before publishing its event. Publishing first has the opposite risk: consumers can see an event for a database change that never committed. A transactional outbox is one approach: write the order and an outbox record in the same database transaction, then relay committed outbox entries to Kafka.

The relay can publish duplicates, so consumers still need an idempotency strategy. Store an event identifier or apply a business update with a uniqueness condition appropriate to the side effect. Kafka transactions offer specific guarantees within Kafka workflows; they do not automatically make an external payment call or arbitrary database write exactly once.

Handle retries without hiding failures

Committing progress before a side effect can lose work after a crash; committing after it can repeat the side effect. Decide what the handler can safely retry and couple progress tracking to the business operation where feasible. Use bounded retries and classify malformed messages separately from transient downstream failures.

A dead-letter topic needs an owner, alerting, retention and a replay procedure. Moving a failed event there does not resolve the underlying order. Retry topics can change ordering relative to later events, so decide whether preserving per-key order matters more than allowing other work to continue.

• Define event IDs, schema evolution and partition keys.
• Test a crash between the side effect and progress commit.
• Document retry limits, replay authorization and duplicate handling.

Operate for lag and recovery

Track consumer lag together with processing rate, error rate and event age. A system may be available while business work is hours behind. Size retention so consumers can recover from realistic outages, and compare recovery throughput with the ongoing arrival rate.

Restrict producer and consumer permissions, encrypt connections and avoid unnecessary personal data in event payloads. Test a consumer rebalance, a broker failure and a poison message. Choose synchronous requests for interactions that truly need an immediate result; Kafka adds durable asynchronous coordination, not free simplicity.