Chapter 15 Flashcards — Event-Driven Architecture
flashcards fsa event-driven async messaging
What are the two primary topologies in Event-Driven Architecture?
?
Broker topology (decentralized, events flow through a message broker with no central coordinator) and Mediator topology (a central event mediator orchestrates workflow steps). Broker maximizes decoupling; Mediator enables complex, stateful workflows.
What is the defining characteristic of the Broker topology in EDA?
?
There is no central coordinator. Producers publish events to a message broker (e.g., Kafka, RabbitMQ), and consumers subscribe to topics independently. Consumers may emit derived events, creating reactive chains. Neither producers nor consumers know about each other.
What is the defining characteristic of the Mediator topology in EDA?
?
A central Event Mediator receives initiating events and orchestrates subsequent processing steps. The mediator knows the workflow; individual event processors do not. It supports conditional logic, parallel steps, and centralized error handling. Examples: Apache Camel, AWS Step Functions.
What is the fundamental difference between an Event and a Message in EDA?
?
An event is a past-tense notification of something that happened (e.g., OrderPlaced) — it carries no intent. A message is a command directing a receiver to do something (e.g., ProcessPayment). True EDA uses events; disguised commands create hidden coupling.
What is a Fat Event and what is its trade-off?
?
A fat event carries all relevant data in its payload (not just an ID). Advantage: consumers are self-sufficient with no need for callbacks. Disadvantage: larger message size, data duplication across consumers, and payload versioning complexity.
What is a Thin Event and what is its trade-off?
?
A thin event carries only an identifier (e.g., orderId). Advantage: small payload, single source of truth remains in the originating service. Disadvantage: consumers must make synchronous callbacks to fetch data, introducing latency and coupling — the opposite of EDA’s goals.
What is a Derived Event?
?
A derived event is a new event emitted by a consumer as a result of processing an upstream event. For example, OrderPlaced triggers inventory service, which emits InventoryReserved, which triggers the shipping service. Derived events enable reactive event chains in the Broker topology.
How does EDA support extreme extensibility?
?
Because producers emit events without knowledge of consumers, new consumers can subscribe to existing event topics at any time without modifying producers or existing consumers. This is the Open/Closed Principle applied at the architecture level — open for extension, closed for modification.
What is a Dead-Letter Queue (DLQ) and why is it essential in EDA?
?
A Dead-Letter Queue receives messages that have failed processing after a configured number of retries. It prevents poison messages (messages that always fail) from blocking the primary queue. Operations teams monitor DLQs to detect failures, investigate root causes, and replay corrected messages.
Why must EDA consumers be idempotent?
?
Most message brokers guarantee at-least-once delivery — a message may be delivered more than once due to retries or redelivery after consumer failure. Idempotent consumers produce the same result whether they process a message once or multiple times, preventing duplicate data or incorrect state from repeated processing.
What are the three message delivery semantics and their trade-offs?
?
At-most-once: may lose events (fire-and-forget). At-least-once: no data loss but possible duplicates — requires consumer idempotency. Exactly-once: no loss and no duplicates, but requires transactional coordination between broker and consumer at significant performance cost.
What is the Acknowledgment pattern in EDA and why does it prevent data loss?
?
A consumer sends an ACK (acknowledgment) to the broker only after successfully processing a message. Until acknowledged, the broker retains the message and redelivers it on consumer failure. This prevents data loss — a message is never discarded until confirmed as processed.
What is the Outbox Pattern and what problem does it solve?
?
The Outbox Pattern solves the dual-write problem. Instead of writing to the database AND publishing to the broker (two operations that can be partially applied), the producer writes the event to a local outbox table in the same database transaction as the business data. A separate relay process reads the outbox and publishes to the broker, ensuring atomicity.
What is the Swarm of Gnats antipattern?
?
Swarm of Gnats occurs when events are designed at too fine a granularity, producing excessive chatty events that overwhelm the broker and fragment business logic across dozens of tiny handlers. The fix is designing events at meaningful business granularity — OrderFulfilled rather than ItemPickedFromShelf, ItemWrapped, ItemLabeled.
How is synchronous request-reply achieved over an async EDA system?
?
Via Correlation IDs and reply-to queues. The requestor publishes a message with a unique correlation ID and a reply-to queue address. The consumer processes and sends a response to the reply-to queue with the same correlation ID. The requestor matches the reply using the ID and enforces a timeout to handle non-responses.
What is a Correlation ID and why is it essential in EDA?
?
A Correlation ID is a unique identifier attached to every event or request message. It is propagated through the entire event chain, enabling distributed tracing, matching async replies to their originating requests, and debugging end-to-end workflows across multiple services.
What is the role of a Schema Registry in EDA?
?
A Schema Registry (e.g., Confluent Schema Registry) stores and enforces event schema versions. It ensures that producers and consumers agree on message structure, enforces backward/forward compatibility rules, and rejects schema changes that would break existing consumers — acting as a governance layer for event contracts.
What are the three Data Topologies available in EDA?
?
Monolithic: all handlers share one database (simple but tightly coupled). Domain: handlers within a domain share a database, but domains are isolated (balanced trade-off). Dedicated: each handler has its own database (maximum decoupling, maximum complexity, data duplication). The dedicated topology aligns with microservices principles.
What is the Mediated EDA (Hybrid) topology?
?
Mediated EDA combines both Broker and Mediator topologies. A mediator orchestrates complex internal workflows, and upon completion, emits a resulting event onto the broker for broader distribution. This allows complex coordination within a bounded context while maintaining loose coupling between domains.
What rating does EDA receive for Scalability and Performance, and why?
?
EDA receives 5 stars (★★★★★) for both Scalability and Performance. Non-blocking asynchronous processing means producers are never blocked by consumers. Consumers scale independently and horizontally. The broker acts as a buffer absorbing traffic spikes, enabling near-unlimited throughput.
What rating does EDA receive for Simplicity and why?
?
EDA receives 1 star (★☆☆☆☆) for Simplicity — the lowest possible. The async mental model, error handling strategies (DLQ, retry, idempotency), distributed tracing, schema governance, and eventual consistency make EDA one of the most operationally complex architecture styles.
What rating does EDA receive for Testability and why?
?
EDA receives 2 stars (★★☆☆☆) for Testability. Asynchronous flows introduce timing dependencies, race conditions, and out-of-order delivery that are inherently difficult to test. End-to-end testing requires a running broker; contract testing between producers and consumers is essential but complex.
Why is event ordering a risk in EDA, and how is it managed?
?
Most brokers guarantee ordering only within a partition or topic, not globally. When business logic depends on event order (e.g., AccountCreated must be processed before AccountDebited), careful partitioning strategy (e.g., partitioning by account ID in Kafka) ensures ordered delivery for related events.
What is Event Schema Evolution and why is it challenging?
?
Event Schema Evolution refers to changing the structure of an event over time. Because producers and consumers are independently deployed, a schema change can silently break consumers still expecting the old format. It requires a schema registry, backward/forward compatibility policies, versioned event types, and careful consumer migration strategies.
What AWS services support EDA, and for which roles?
?
SNS (pub/sub fan-out), SQS (queuing, DLQ), EventBridge (event bus routing), Kinesis (high-throughput streaming) for brokering. Step Functions and EventBridge Pipes for mediated/orchestrated workflows. Together they cover both Broker and Mediator EDA topologies natively.
What is the Open/Closed Principle at the architecture level in EDA?
?
In EDA, the system is open for extension (new consumers can subscribe to existing events to add behavior) but closed for modification (existing producers and consumers do not need to change). This architectural property makes EDA the highest-extensibility style for systems that frequently add new downstream behaviors.
What are the key characteristics of EDA that make it suitable for IoT and real-time analytics?
?
EDA supports high-throughput ingestion of millions of events per second, fan-out delivery to multiple consumers (analytics, alerting, storage) simultaneously, async buffering to absorb bursts, and stream processing semantics. These make it the natural choice for IoT telemetry pipelines and real-time analytics platforms.
What is the biggest operational challenge of the Broker topology compared to Mediator?
?
In the Broker topology, there is no single place to observe the state of a multi-step workflow. Each event flows independently, making end-to-end visibility difficult. Distributed tracing (Jaeger, Zipkin, AWS X-Ray) with correlation IDs is mandatory to reconstruct workflow execution across services.
How does EDA handle backpressure and traffic spikes?
?
The message broker acts as a buffer between producers and consumers. When consumers are slower than producers, the broker holds messages in the queue. Consumers process at their own rate without causing producer failures. This temporal decoupling naturally absorbs traffic spikes without requiring consumers to scale instantaneously.
When is EDA a poor architectural choice?
?
EDA is a poor fit when: the system requires immediate, synchronous responses (user-facing APIs with strict latency SLAs); the application is a simple CRUD system with no event propagation needs; strong immediate consistency is required; or the team is too small to absorb the operational complexity of broker management, DLQs, schema registries, and distributed tracing.
What are the five major risks of Event-Driven Architecture?
?
- Complex error handling — failures are silent without monitoring. 2. Workflow state invisibility — no central view of multi-step workflows. 3. Message ordering — global ordering is not guaranteed. 4. Eventual consistency — strong consistency is not achievable. 5. Duplicate processing — at-least-once delivery requires universal idempotency.
What is Exponential Backoff in EDA retry handling?
?
Exponential Backoff is a retry strategy where the wait time between consecutive retry attempts doubles (or grows exponentially) with each failure. For example: retry after 1s, 2s, 4s, 8s… This prevents retry storms that could overwhelm a struggling downstream service and is standard practice in retry queue configurations.
What is the purpose of a Reply-To Queue in async request-reply?
?
A Reply-To Queue is a dedicated queue (often temporary or exclusive per requestor) where a service should send its response. The requestor includes the reply-to address in the request message. This avoids hard-coding routing in the consumer and allows multiple requestors to receive independent responses via their own reply queues.
Total Cards: 33
Estimated Review Time: 25-30 minutes
Priority: HIGH
Last Updated: 2026-05-29