Event-Driven Architecture

Event-driven architecture is a style of software design in which the parts of a system communicate by announcing that something has happened, instead of calling one another directly and waiting for an answer. Each announcement is an event: a small record of a fact, such as "payment authorized" or "account credited", with the relevant details and a timestamp. Other components subscribe to the kinds of event they care about and act when one arrives.

The approach suits payments, where a single transaction touches many functions, including authorization, fraud checks, ledger posting, notifications, settlement and reporting, and where many steps complete at different times. It is commonly used together with microservices, and it is the internal counterpart of the webhooks that payment companies send to their customers.

A producer is a component that publishes events. A consumer is a component that receives and processes them. Between the two sits a broker, software that accepts events, stores them and delivers them to every interested consumer. The producer does not know who the consumers are, so new ones can be added freely.

Brokers come in two broad kinds. A message queue delivers each message to one worker, which suits tasks that must be done once. An event stream or log keeps an ordered, durable history that many consumers can read independently and replay from any point. In both cases communication is asynchronous: the producer continues its work without waiting for consumers to finish.

Consider a card payment received by a payment processor. The service that handles the request obtains an authorization and publishes a "payment authorized" event. Several consumers react in parallel. The ledger service posts the entries to its double-entry ledger. The risk service updates the customer's profile for real-time fraud scoring of later transactions. The notification service sends the merchant a webhook notification. Later, the settlement service publishes "payment settled", and the reconciliation and payout services respond to that.

If these functions were chained together as direct calls, a slow notification system would delay every payment, and a failure in analytics could cause an authorization to fail. With events, each consumer works at its own pace, and one that is unavailable catches up when it returns.

• Publish and subscribe. One event is delivered to many independent subscribers.
• Event sourcing. The system stores the full sequence of events as its primary record and derives current state, such as a balance, by replaying them. This gives a natural audit trail and matches the append-only nature of financial ledgers.
• Sagas. A business process that spans several services, such as debiting one account, converting currency and crediting another, is run as a series of local steps linked by events, with compensating actions to undo earlier steps if a later one fails.
• Transactional outbox. A service writes its data change and the event describing it in one database transaction, and a separate process publishes the event, so that the two cannot fall out of step.
• State machines. Each payment moves through defined states in response to events, an arrangement described under payment state machine.

Most brokers guarantee that an event will be delivered at least once, which means it may occasionally be delivered twice. In payments a duplicate could mean a double credit, so consumers must be designed for idempotency: processing the same event a second time must have no further effect. This is usually achieved by recording the identifiers of events already handled.

Order matters as well. A "refund issued" event processed before the "payment captured" event it relates to would produce nonsense. Systems preserve order by routing all events for one payment or account through the same partition, or by having consumers check the current state before acting.

Because consumers update at different moments, the system as a whole is only eventually consistent. For a short time after a payment, the ledger may show it while the reporting database does not. Designers must decide which operations can tolerate this and which, such as checking a balance before approving a withdrawal, need an immediate and authoritative answer.

Event-driven design complements, and does not replace, synchronous interfaces. A merchant still creates a payment by calling a REST API and receiving a reply. Events take over for what follows, particularly for an asynchronous payment whose result arrives later. Externally, the provider delivers events as webhooks and resends failures under a webhook retry policy; internally, the same events drive its own services.

Banks use the pattern to modernize around an older core banking system. Changes in the core are captured and published as events, and newer services for mobile apps, fraud monitoring and customer alerts consume them without adding load to the core. Instant payment schemes, which require a response within seconds at any hour, and the richer data carried by ISO 20022 messages have encouraged this move away from overnight batch processing.

The flexibility comes at a price. A flow spread across many services and events is harder to follow and to debug than a single sequence of calls, and it requires tooling to trace one transaction through the system. The broker is critical infrastructure whose failure or delay affects everything, so its availability and latency must be monitored closely.