What Is Event-Driven Architecture? | Vantage

Event-Driven Architecture Event-driven architecture (EDA) is a software design pattern where services communicate by producing and consuming events rather than making direct synchronous calls to each other. An event is an immutable record of something that happened (OrderPlaced, UserSignedUp, PaymentFailed). Producers emit events to an event broker (Kafka, RabbitMQ, AWS SNS/SQS) without knowing which consumers will handle them. Consumers subscribe to relevant events and process them independently. This decoupling allows services to evolve, scale, and fail independently.

Why event-driven architecture matters

Synchronous service-to-service calls create tight coupling: if Service B is slow or unavailable, Service A also degrades. Event-driven architectures decouple services in time and space — Service A emits an event and moves on; Service B processes it when it is ready. This enables independent scaling (if order processing is slow, add more order workers without touching the checkout service), resilience (failed consumers retry without affecting producers), and new integrations (add analytics, notifications, or auditing without modifying the producing service).

How it works

Services publish events to topics on an event broker when significant state changes occur. Events are immutable and ordered within a partition (Kafka) or queue (RabbitMQ). Consumers subscribe to topics and process events asynchronously. Failed events are retried (with exponential backoff) or sent to a dead-letter queue for inspection. Event schemas are defined in a schema registry (Confluent, AWS Glue) to ensure producers and consumers agree on the event format. Event sourcing (a related pattern) stores events as the primary source of truth rather than current state.

Common mistakes

• Using events for synchronous operations where a response is needed immediately — event-driven is not suitable when the caller needs an immediate answer

• No dead-letter queue strategy — messages that fail repeatedly must go somewhere; without DLQ, they are silently dropped

• Over-engineering with EDA — direct synchronous calls are simpler when services are tightly coupled and low-volume

• Evolving event schemas without backward compatibility — adding required fields breaks existing consumers

• Not monitoring consumer lag — a consumer that is falling behind its queue is a warning sign that needs immediate attention