Master Event-Driven Architecture (EDA) Interviews for All Experience Levels
Event-Driven Architecture (EDA) is essential for building scalable, responsive systems. This comprehensive guide covers 30 interview questions arranged from basic to advanced, perfect for freshers, 1-3 years, and 3-6 years experienced candidates preparing for roles at companies like Zoho, Salesforce, and Atlassian.
Basic Level Questions (1-10)
1. What is Event-Driven Architecture (EDA)?
Event-Driven Architecture is a software design pattern where system components communicate by producing and consuming events. Instead of direct calls, services react asynchronously to events like “UserRegistered” or “OrderPlaced”, enabling loose coupling and scalability.[1][5]
2. How does EDA differ from traditional request-response architecture?
In traditional architectures, components make synchronous calls and wait for responses. EDA uses asynchronous event publishing where producers don’t wait for consumers, allowing independent scaling and better fault tolerance.[1][4]
3. What are the core components of an EDA system?
The main components are:
- Event Producers: Generate events
- Event Consumers: Process events
- Event Broker: Routes events between producers and consumers
- Event Store: Persists events (optional)
[3][5]
4. What is the role of an event broker in EDA?
An event broker acts as a central hub that receives events from producers, stores them temporarily, and routes them to subscribed consumers. It ensures reliable delivery and decoupling between components.[1][5]
5. What are the primary benefits of Event-Driven Architecture?
Key benefits include:
- **Decoupling**: Producers and consumers are independent
- **Scalability**: Components scale independently
- **Resilience**: One failure doesn’t crash the entire system
- **Real-time processing**: Immediate reactions to events
[4][5]
6. What is an event in the context of EDA?
An event is a record of something that happened in the system, containing data about the occurrence (e.g., “OrderPlaced” with order details). Events are immutable and represent facts, not commands.[4][1]
7. Explain the publish-subscribe pattern in EDA.
In publish-subscribe, producers publish events to topics without knowing consumers. Consumers subscribe to topics of interest and receive relevant events automatically through the broker.[1][3]
8. What is event sourcing?
Event sourcing persists the state of an application as a sequence of immutable events. Instead of storing current state, you store all state-changing events and derive current state by replaying them.[4][1]
9. Why is loose coupling important in EDA?
Loose coupling means producers don’t need to know consumer locations, technologies, or availability. This enables independent development, deployment, and scaling of services.[4][3]
10. When is EDA most suitable for a system?
EDA excels in real-time applications, systems requiring independent scaling, complex workflows, and scenarios with unpredictable loads like e-commerce order processing or IoT data streams.[5][7]
Intermediate Level Questions (11-20)
11. What challenges does EDA introduce compared to synchronous systems?
Challenges include:
- Eventual consistency (not immediate)
- Debugging distributed event flows
- Managing event schema evolution
- Ensuring exactly-once processing
[4][1]
12. Explain the Competing Consumers pattern.
In Competing Consumers, multiple consumer instances compete to process messages from a single queue. This enables horizontal scaling as load increases, with each consumer processing messages independently.[6]
// Pseudo-code for competing consumers
while (queue.hasMessages()) {
Message msg = queue.poll();
processEvent(msg);
queue.acknowledge(msg);
}
13. How do you ensure message ordering in EDA?
Message ordering is maintained within partitions using keys (e.g., customer ID). Timestamps help handle out-of-order events, and designing commutative operations reduces ordering dependency.[4]
14. What is the difference between events, commands, and messages?
- Event: Something that happened (past tense, factual)
- Command: Request to make something happen (imperative)
- Message: Generic term for any data sent between components
[4]
15. How would you implement retry logic in an EDA system at Paytm?
Implement retry with exponential backoff, distinguish transient vs permanent errors, set maximum retry limits, and route unprocessable events to a Dead Letter Queue (DLQ) for analysis.[6]
16. What is fanout messaging in EDA?
Fanout occurs when a single event triggers multiple consumers simultaneously. One “OrderPlaced” event can notify inventory, payment, shipping, and analytics services concurrently.[3]
17. Explain choreography vs orchestration in EDA.
Choreography: Services coordinate through events without a central controller. Orchestration: A central service directs workflow (less common in pure EDA).[4]
18. How do you handle schema evolution in event payloads?
Use backward/forward compatible schemas, versioning in event names (e.g., “UserRegistered_v2”), optional fields, and contract testing to ensure producers/consumers compatibility.[3]
19. What is the Dispatcher pattern in EDA?
The Dispatcher routes events to appropriate handlers based on event type or content. It manages event processing flow and load balances across multiple consumer instances.[5]
20. At Zoho, how would you design an event aggregator?
An aggregator combines multiple related events into a single meaningful event (e.g., multiple “ItemAddedToCart” → “CheckoutReady”), simplifying downstream processing.[5]
Advanced Level Questions (21-30)
21. How do you achieve exactly-once semantics in EDA?
Combine idempotent consumers, transactional outbox pattern, and broker-level deduplication. Ensure operations are repeatable without side effects.[4]
22. Explain the trade-offs of event sourcing at Salesforce scale.
Pros: Complete audit trail, temporal queries, easy state reconstruction.
Cons: Complex queries (mitigated by snapshots), steep learning curve, schema evolution challenges.[4]
23. What is the Retry Messages pattern and when to use it?
Automatically retry failed message processing with exponential backoff. Use for transient failures (network issues, temporary overload) but route permanent failures to DLQ.[6]
24. How would you implement Saga pattern in EDA for Swiggy’s order workflow?
Each service publishes compensating events on failure. “PaymentFailed” triggers “ReleaseInventory” and “CancelOrder”, maintaining consistency across distributed transactions.[1]
25. Design an idempotency mechanism for event consumers.
Store processed event IDs in a fast lookup store (Redis/Cache). Before processing, check if event ID exists. Use event metadata or business entity IDs for deduplication.[6]
public boolean processEvent(OrderPlaced event) {
String eventId = event.getId();
if (processedEvents.contains(eventId)) {
return true; // Already processed
}
// Process business logic
processedEvents.add(eventId);
return true;
}
26. How do you monitor and debug event flows in production?
Use distributed tracing (event correlation IDs), metrics on lag/throughput, event schema validation, and comprehensive logging with event lineage tracking.[3]
27. What are the consistency challenges in EDA and how to address them?
EDA provides eventual consistency. Use CQRS (Command Query Responsibility Segregation) with separate read models updated asynchronously from event streams.[4]
28. At Atlassian, how would you handle event stream partitioning for scalability?
Partition by business entity keys (user ID, project ID) to maintain order within partitions while enabling parallel processing across partitions.[4]
29. Explain the Async Request-Response pattern in EDA.
Producer sends request event with correlation ID. Consumer processes and publishes response event with same ID. Producer listens for matching response events.[6]
30. How do you test Event-Driven systems comprehensively?
- Unit tests: Individual event handlers
- Contract tests: Event schema validation
- Integration tests: End-to-end event flows with mocked brokers
- Chaos testing: Simulate broker failures, network partitions
[3]
