Architecture Patterns

Event-Driven Architecture

Term 33 of 68 in the ERPStack technical glossary

What is Event-Driven Architecture?

Event-Driven Architecture is a software architecture pattern where database changes, transactions, and user events trigger background services asynchronously via message brokers.

Event-Driven Architecture at a glance

Shape: 1 producer, N consumers — adding a consumer requires 0 changes to the producer
Transport: Apache Kafka topics for durable ordered logs; HMAC-SHA256 signed webhooks for external delivery
Delivery guarantee: At-least-once by default, so 100% of consumers must be idempotent on replay
Ordering: Guaranteed within 1 partition only, so the partition key is a design decision, not a default
Built with: Apache Kafka topics consumed by TypeScript 5.9 workers in Docker and Kubernetes, writing to PostgreSQL 18 via Drizzle ORM 0.45, with Sentry and OpenTelemetry Observability on every consumer
Numbers that matter: 1 producer, N consumers; ordering within 1 partition only; 100% of handlers idempotent; 4 consumers make a field a published contract
Transport options: Apache Kafka, Redis streams, or signed webhooks for external consumers
Commonly paired with: Microservices Architecture, the Saga Pattern, ClickHouse analytics, Redis, Docker and Kubernetes workers, and Sentry
Replay window: Apache Kafka retains a topic for 604800000 milliseconds — 7 days — by default, so a consumer added on day 3 replays the backlog instead of starting empty.
Where it earns its keep: logistics, manufacturing and retail flows, where 1 dispatch event has to reach the ClickHouse analytics database, a TimescaleDB series and 2 partner systems without the producer knowing any of them exist.

How Event-Driven Architecture works in production

In an event-driven setup, applications do not wait for background tasks (e.g., sending notification emails, updating analytics logs) to finish. The system publishes an event (e.g., 'Order Placed') to a queue, and background workers process it, keeping user response times low.

The ERPStack approach to Event-Driven Architecture

We design event-driven backends using AWS SQS or Redis queues, ensuring that heavy operations do not slow down user interfaces.

Related Resources

Frequently asked questions about Event-Driven Architecture

What does Event-Driven Architecture change about coupling?

It inverts who knows about whom. In Event-Driven Architecture the producer publishes a fact — order placed, invoice paid — and has no knowledge of consumers. Adding analytics, notifications or a fraud check means adding a subscriber, with 0 changes to the code that emitted the event. That is the real benefit: new capability without editing the critical path that already works.

Why must every consumer be idempotent?

Because delivery is at-least-once. Event-Driven Architecture systems retry when an acknowledgement is lost, so the same message will eventually be processed twice. If the handler increments a balance or sends an email without a de-duplication key, the duplicate becomes a visible business error. Storing a processed-event identifier and short-circuiting on replay costs 1 table and removes an entire class of incident.

How is ordering handled in an event log?

Per partition, not globally. Event-Driven Architecture on Apache Kafka guarantees order within 1 partition, so events that must be sequenced — everything for a single order, say — need a partition key that routes them together. Choosing the wrong key produces a system that is correct in testing and subtly wrong in production, where 2 updates for the same entity land out of order.

What is the hardest part of going event-driven?

Debugging, and schema evolution. Event-Driven Architecture removes the stack trace that used to connect cause to effect, so distributed tracing through OpenTelemetry stops being optional. Events are also a published contract: once 4 consumers depend on a field, removing it is a breaking change. Additive-only event schemas with explicit versions are the discipline that keeps this manageable.