status
this chapter is in active development
expect live edits and rapid iteration (except for when i am really busy with other stuff) while this material is written.
why async exists and what you give up when you choose it.
event-driven architecture is a way of structuring systems where components communicate by producing and consuming events rather than by calling each other directly. the appeal is decoupling: the component that produces an event does not need to know who cares about it or what they do with it. the cost is that you give up the simplicity of knowing whether your request was handled.
understanding why event-driven systems exist, what problem they solve, is more useful than memorizing the pattern.
in a synchronous system, service A calls service B and waits for a response. this is simple and debuggable, but it creates tight coupling:
for simple systems with few dependencies, synchronous coupling is fine. as the number of dependencies grows, or as the need for resilience increases, the limitations become painful.
events decouple producers from consumers. service A emits "order placed." it does not call the billing service, the inventory service, and the notification service in sequence. it emits an event and moves on. those services subscribe to the event and react independently.
this buys you:
temporal decoupling. A produces the event and returns immediately. the consumers process it when they can, at their own pace, without holding A's thread. if a consumer is slow or temporarily down, the events queue up and are processed when the consumer recovers.
additive extension. to react to a new event with a new service, subscribe to the event. you do not modify the producer. the producer does not know or care that a new consumer exists.
resilience to consumer failures. if the billing service goes down, orders are not lost. they queue in the event log. when billing recovers, it processes the backlog. with synchronous calls, a billing outage would cause order placement to fail.
audit trails. if you record events, you have a history of everything that happened. this is useful for debugging, auditing, and replaying events to rebuild derived state.
the decoupling is real but it comes with costs:
you lose synchronous confirmation. when A emits an event, it does not know if the event was processed successfully. the billing service might have failed. the inventory service might have processed the event twice. the notification service might have sent the wrong message. A returned success to the user; the downstream effects are uncertain.
this requires idempotency (consumers must handle duplicate events safely), eventual consistency (the system converges to the correct state but may be inconsistent in the interim), and compensating actions for failures.
debugging is harder. tracing what happened in a synchronous system is reading a stack trace. tracing what happened in an event-driven system is following an event through multiple services, correlating by event ID, and reconstructing a timeline from disparate logs. distributed tracing tooling helps, but the cognitive overhead is higher.
event schemas become API contracts. once consumers depend on an event's schema, you cannot change it freely. breaking changes in events break all consumers, and unlike API versioning, you cannot always force consumers to upgrade. schema evolution requires care: additive changes are safe, removing fields breaks consumers, changing field semantics breaks consumers silently.
event ordering is not guaranteed by default. if service A produces two events for the same entity in quick succession, consumers may receive them out of order. systems that require ordered processing need to partition events by key and ensure consumers process each key's events in order, which adds complexity.
event-driven architecture is a good fit when:
it is less suited to:
the infrastructure that stores events (Kafka, Kinesis, Pulsar, or a database-backed queue) is central to event-driven systems. the log provides durability (events are not lost if a consumer is down), replay (consumers can reprocess old events), and ordering guarantees within partitions.
the log's retention policy and partition strategy are design decisions with long-term consequences. how long do you keep events? can consumers replay from the beginning? how do you partition to ensure ordered processing where needed?
these operational questions are part of the architecture. choosing event-driven commits you to answering them.