Event-Driven Architecture: Events, Brokers, Idempotency, Ordering, and Schema Evolution

Event-Driven Architecture: Events, Brokers, Idempotency, Ordering, and Schema Evolution

An event-driven system lets producers publish facts that happened while consumers react independently.

Events vs Commands

An event describes a completed fact:

OrderPlaced
PaymentCaptured
UserEmailChanged

A command asks a specific owner to perform an action:

CapturePayment
SendInvoice

Keeping that distinction clear makes ownership and retries easier to reason about.

Assume Duplicate Delivery

Many messaging systems can redeliver messages after failures. Consumers should be idempotent using stable event/business IDs, unique constraints, or processed-message state.

Do not let a retried PaymentCaptured event credit an account twice.

Order Only What Must Be Ordered

Global ordering reduces scalability. Preserve ordering at the smallest useful scope, often through a partition key such as order_id or customer_id.

Kafka, for example, preserves order within a partition—not across an entire multi-partition topic.

Version Event Schemas

Producers and consumers deploy independently, so event contracts must evolve compatibly. Prefer additive changes, explicit versions when needed, tolerant consumers, and a schema registry/validation process for important streams.

Handle Poison Messages

Retries should be bounded. Messages that repeatedly fail can move to a dead-letter/error path for investigation or controlled redrive rather than blocking healthy work forever.

Publish Database Changes Reliably

If a service commits business data and then separately publishes an event, a crash between those operations can lose the event.

The transactional outbox pattern records the business change and outgoing event in one local transaction, then publishes from the outbox asynchronously.

Backpressure Still Matters

A broker buffers load; it does not create infinite processing capacity. Monitor queue/consumer lag and oldest-message age, bound retries/concurrency, and scale consumers according to downstream capacity.

Final Takeaway

Event-driven architecture works well when services benefit from loose runtime coupling and asynchronous reactions. Make event meaning explicit, consumers idempotent, ordering scoped, schemas compatible, failed messages recoverable, and publication reliable.

References

• Azure Architecture Center: Event-Driven Architecture
• AWS Transactional Outbox Pattern
• Apache Kafka Introduction