Event-Driven Architecture

How the event loop works

Three roles define the pattern. Producers generate events, which represent something that has already happened: the naming convention is past tense, such as OrderPlaced or PriceChanged, in contrast to commands that instruct something to happen. An event broker or message bus, such as Apache Kafka or RabbitMQ, receives each event, often persists it, and distributes it to interested parties. Consumers subscribe to the events they care about and process them asynchronously, without the producer waiting for a response.

Because producers and consumers never call each other directly, they are decoupled in two ways: temporally, since a consumer can process an event moments or minutes after it was emitted, and functionally, since a producer neither knows nor cares which consumers exist. One event can fan out to many consumers. An OrderPlaced event, for instance, can simultaneously trigger a payment service, an inventory service, and an email service, each running on its own and scaling independently. This produces cascades of events that are causally related but otherwise independent, which is what gives the architecture its loose coupling and real-time responsiveness.

Event-driven architecture vs. polling

The contrast with polling is the distinction the working definition draws, and it is the one most relevant to monitoring tools. In a polling model, a consumer periodically asks a source whether anything has changed, every minute, every hour, on whatever interval the schedule sets. That introduces two costs: detection lag, because a change that lands just after a poll waits until the next one to be noticed, and wasted work, because most polls return nothing new yet still consume requests and compute.

EDA inverts the flow. Instead of the consumer pulling on a timer, the producer pushes an event the instant a change occurs, and the broker delivers it to consumers immediately. The lag between a change and its detection collapses toward the processing time of the pipeline rather than the length of the polling interval. The trade-off is infrastructure: polling needs only a scheduled job, while EDA needs a broker, subscription management, and handling for ordering and delivery guarantees. Many real systems blend both, event-driven where latency matters, scheduled polling where a source cannot emit events.

EDA, pub/sub, webhooks, and event streaming

Several adjacent terms are easy to conflate with EDA because they describe mechanisms that implement it rather than the paradigm itself. Publish/subscribe, or pub/sub, is the dominant messaging pattern used to realize EDA: publishers send events to a broker, and subscribers receive the ones they registered for. Pub/sub is a mechanism; EDA is the broader architecture that pub/sub commonly delivers.

Event streaming refers to the underlying data infrastructure, Kafka is described as a distributed event-streaming platform, that stores and moves events at scale. EDA is the architectural pattern built on top of that technology. Webhooks are narrower still: a webhook is a push-based HTTP callback delivering one type of event from one source to one endpoint, whereas EDA typically routes many event types from many producers to many consumers through a broker that can filter and fan them out. A webhook can be one edge of an event-driven system, but it is not the system. Complex event processing is a related technique layered on top of EDA to detect patterns across multiple correlated events rather than reacting to single events in isolation.

Why it matters for competitive monitoring

For a competitive-intelligence platform, event-driven architecture is the conceptual reason changes surface as they happen instead of on a fixed refresh cadence. When a monitor detects a new competitor blog post, a pricing-page edit, or a fresh job listing, that detection can be treated as an event that immediately triggers downstream work, scoring the change, routing an alert, updating a dashboard, rather than sitting in a queue until the next scheduled scan reviews everything at once.

In practice, monitoring systems often combine event-driven and scheduled elements. The initial data collection may still run on a polling interval, because a competitor's website does not notify anyone when it changes. But once a change is detected, event-driven processing takes over: the detection becomes an event, and the pipeline reacts to it asynchronously. This is why the pattern is worth understanding even for non-engineers on a CI team, it explains both what real-time alerting can deliver and where the residual lag comes from, since a system is only as fast as the step that first notices the change.

Frequently Asked Questions

Related terms