Event-Driven Systems Architect Interview Questions
5 exercises — choose the best-structured answer to common Event-Driven Architect interview questions. Focus on precise vocabulary, correct use of technical terms, and demonstrating real experience.
Structure for EDA answers
Tip 1: Name the pattern precisely: event notification, event-carried state transfer, event sourcing, CQRS
Tip 2: Address consistency: eventual consistency vs. strong consistency, saga pattern for distributed transactions
Tip 4: Failure modes: at-least-once delivery, idempotency keys, dead-letter queues
0 / 5 completed
1 / 5
The interviewer asks: "What is the difference between event notification and event-carried state transfer?" Which answer best demonstrates EDA pattern knowledge?
Option B is strongest because it precisely defines both patterns, explains the architectural trade-off, and introduces the related event sourcing pattern. Key structure: notification (lightweight + callback) → state transfer (embedded state, no callback) → sourcing (immutable log). Option A confuses the patterns with processing paradigms. Option C reverses the size relationship. Option D is incorrect — the patterns have fundamentally different architectural implications.
2 / 5
The interviewer asks: "How does the Outbox Pattern solve dual-write consistency?" Which answer best demonstrates distributed systems expertise?
Option B is strongest because it identifies the root problem, explains the Outbox Pattern mechanism precisely, and addresses the idempotency requirement. Key structure: business write + outbox row → single transaction → CDC relay → broker → idempotent consumers. Option A (XA transactions) are practically unavailable for most modern brokers and introduce significant performance overhead. Option C (broker-first) creates a window where the broker has the event but the DB write fails. Option D confuses the Outbox Pattern with the Saga Pattern.
3 / 5
The interviewer asks: "How do you choose a Kafka partition key?" Which answer best demonstrates Kafka architecture understanding?
Option C is strongest because it explains the purpose of partition keys, provides a concrete strategy with a real example, identifies the hot partition anti-pattern, and warns about the schema change risk. Key structure: same key → same partition → ordered processing → choose entity that needs ordering → avoid low-cardinality. Option A (random key) destroys ordering guarantees. Option B (timestamp) does not group related messages together. Option D misunderstands how consumer groups and partitions relate.
4 / 5
The interviewer asks: "How do you implement a distributed saga for a multi-service checkout flow?" Which answer best demonstrates distributed transaction expertise?
Option B is strongest because it distinguishes orchestration vs. choreography, demonstrates the checkout flow concretely, and names the compensating transaction pattern with its isolation trade-off. Key structure: orchestration vs. choreography → command/reply → compensating transactions on failure → idempotency keys → eventual consistency. Option A (2PC) does not work across heterogeneous services and creates blocking. Option C (try/catch rollback) is naive and does not account for partial failures in distributed systems. Option D misunderstands Kafka transactions — they scope to producer/consumer, not cross-service calls.
5 / 5
The interviewer asks: "What guarantees does Kafka provide, and what does it NOT guarantee?" Which answer best demonstrates precise Kafka knowledge?
Option B is strongest because it lists what Kafka does guarantee, what it does not, the configuration required for stronger guarantees, and the important distinction between delivery and processing guarantees. Key structure: at-least-once + partition ordering + durability (guaranteed) vs. exactly-once + cross-partition ordering + deduplication (not guaranteed by default). Option A incorrectly states ordering across partitions is guaranteed. Option C invents a 30-second acknowledgement window. Option D is incorrect — Kafka does provide delivery guarantees at the at-least-once level.