Backend interview prep

Start

Event-Driven Architecture Interview Questions and Answers (Top 10)

Top 10 real-world Event-Driven Architecture interview questions and answers covering events, commands, Event Sourcing, CQRS, Saga, Outbox Pattern, Kafka, and production best practices.

Event-Driven Architecture Interview Questions and Answers (Top 10)

Modern enterprise applications are moving away from tightly coupled synchronous communication toward Event-Driven Architecture (EDA).

Instead of services calling each other directly using REST APIs, services publish events whenever something important happens.

Other services subscribe to these events and react independently.

EDA is widely used in:

  • Banking
  • E-Commerce
  • Insurance
  • Healthcare
  • IoT
  • Logistics
  • Financial Trading

It enables scalable, resilient, and loosely coupled distributed systems.

Event-Driven Architecture

flowchart LR

OrderService["Order Service"] --> Kafka

Kafka --> InventoryService["Inventory Service"]

Kafka --> PaymentService["Payment Service"]

Kafka --> NotificationService["Notification Service"]

Kafka --> AnalyticsService["Analytics Service"]

Q1. What is Event-Driven Architecture (EDA)?

Answer

Event-Driven Architecture is an architectural style where applications communicate through events instead of direct service calls.

An event represents something that has already happened.

Examples:

  • Order Created
  • Payment Completed
  • Customer Registered
  • Account Credited

Benefits:

  • Loose Coupling
  • Scalability
  • High Availability
  • Asynchronous Processing
  • Better Fault Isolation

Event Flow

flowchart LR

Producer --> EventBroker["Event Broker"]

EventBroker["Event Broker"] --> Consumers

Real-Time Example

Customer Places Order

↓

OrderCreated Event

↓

Inventory

↓

Payment

↓

Notification

↓

Analytics

Q2. What is the difference between an Event and a Command?

Answer

A Command tells another service to perform an action.

An Event informs other services that an action has already occurred.

Examples

Command:

Process Payment

Event:

Payment Processed

Comparison

Command Event
Intent Fact
Sent to One Service Published to Many
Expects Action Announces Completion
Tightly Directed Loosely Coupled

Diagram

flowchart LR

Command --> PaymentService["Payment Service"]

PaymentService["Payment Service"] --> PaymentprocessedEvent["PaymentProcessed Event"]

PaymentprocessedEvent["PaymentProcessed Event"] --> Notification

PaymentprocessedEvent["PaymentProcessed Event"] --> Analytics

Q3. Why is Event-Driven Architecture preferred in Microservices?

Answer

REST-based communication creates tight dependencies.

With EDA:

  • Services work independently.
  • New consumers can be added without changing producers.
  • Systems remain available even when one service is temporarily unavailable.

Microservices

flowchart LR

OrderService["Order Service"] --> Kafka

Kafka --> Inventory

Kafka --> Shipping

Kafka --> Email

Kafka --> Audit

Interview Tip

EDA improves scalability by reducing service-to-service dependencies.

Q4. What is Event Sourcing?

Answer

Event Sourcing stores every state change as an event.

Instead of storing only the latest state:

Balance = ₹5000

The system stores:

Account Created

↓

₹1000 Deposited

↓

₹500 Deposited

↓

₹200 Withdrawn

The current balance is reconstructed by replaying events.

Event Store

flowchart TD

EventStore["Event Store"] --> Event1["Event 1"]

EventStore["Event Store"] --> Event2["Event 2"]

EventStore["Event Store"] --> Event3["Event 3"]

EventStore["Event Store"] --> CurrentState["Current State"]

Benefits

  • Complete Audit History
  • Replay
  • Debugging
  • Compliance

Q5. What is CQRS?

Answer

CQRS (Command Query Responsibility Segregation) separates:

  • Write Operations (Commands)
  • Read Operations (Queries)

Architecture

flowchart LR

CommandApi["Command API"] --> WriteModel["Write Model"]

WriteModel["Write Model"] --> Kafka

Kafka --> ReadModel["Read Model"]

ReadModel["Read Model"] --> QueryApi["Query API"]

Benefits

  • Better Performance
  • Independent Scaling
  • Optimized Reads

Q6. What is the Saga Pattern?

Answer

Saga manages distributed transactions using local transactions and compensation.

Instead of one global transaction:

Order

↓

Payment

↓

Inventory

↓

Shipping

Each service completes its own transaction.

If a later step fails, compensating actions reverse previous work.

Saga Flow

flowchart LR

Order --> Payment

Payment --> Inventory

Inventory --> Shipping

Compensation

flowchart LR

InventoryFailed["Inventory Failed"] --> RefundPayment["Refund Payment"]

RefundPayment["Refund Payment"] --> CancelOrder["Cancel Order"]

Q7. What is the Outbox Pattern?

Answer

The Outbox Pattern prevents the Dual Write Problem.

Business data and the event are stored together in one database transaction.

A CDC tool (such as Debezium) later publishes the event to Kafka.

Outbox Flow

flowchart TD

BusinessTransaction["Business Transaction"] --> Database

BusinessTransaction["Business Transaction"] --> OutboxTable["Outbox Table"]

OutboxTable["Outbox Table"] --> Debezium

Debezium --> Kafka

Benefits

  • Reliable Event Publishing
  • Atomic Writes
  • No Lost Events

Q8. What are common Event-Driven Architecture challenges?

Answer

Common challenges include:

  • Duplicate Events
  • Event Ordering
  • Event Versioning
  • Monitoring
  • Event Replay
  • Eventual Consistency
  • Schema Evolution

Event Lifecycle

flowchart LR

Producer --> Kafka

Kafka --> Consumer

Consumer --> Database

Best Practice

Design every consumer to be idempotent.

Q9. How do you monitor Event-Driven systems?

Answer

Monitor:

  • Event Throughput
  • Consumer Lag
  • Failed Events
  • DLQ Size
  • Processing Time
  • Retry Count
  • Replay Operations

Monitoring

flowchart TD

Kafka --> Prometheus

Prometheus --> Grafana

Grafana --> Alerts

Important Metrics

  • Consumer Lag
  • Retry Rate
  • Event Processing Time
  • DLQ Growth

Q10. What are the production best practices for Event-Driven Architecture?

Answer

Follow these recommendations:

  • Use immutable events.
  • Version event schemas.
  • Implement idempotent consumers.
  • Configure retries and DLQs.
  • Use the Outbox Pattern.
  • Use Saga for distributed transactions.
  • Monitor event processing continuously.
  • Secure brokers using TLS.
  • Implement replay services.
  • Document event contracts.

Production Architecture

flowchart TD

RestApi["REST API"] --> OrderService["Order Service"]

OrderService["Order Service"] --> Outbox

Outbox --> Debezium

Debezium --> Kafka

Kafka --> Inventory

Kafka --> Payment

Kafka --> Notification

Kafka --> Analytics

Enterprise Checklist

Area Best Practice
Events Immutable
Event Contracts Schema Registry
Publishing Outbox Pattern
Transactions Saga Pattern
Consumers Idempotent
Failed Events DLQ
Retry Exponential Backoff
Monitoring Prometheus + Grafana
Security TLS
Replay Dedicated Replay Service

Real Banking Scenario

A customer transfers ₹2,00,000.

Transfer Service

↓

TransferCompleted Event

↓

Fraud Detection

↓

Notification

↓

Audit

↓

Analytics

↓

Reporting

Each downstream service processes the same event independently without requiring direct communication with the Transfer Service.

Senior Interview Tips

Interviewers commonly ask follow-up questions such as:

  • Event vs Command?
  • Why use Event-Driven Architecture?
  • What is Eventual Consistency?
  • What is Event Sourcing?
  • What is CQRS?
  • What is the Saga Pattern?
  • What is the Outbox Pattern?
  • How do you handle duplicate events?
  • How do you version events?
  • How do you replay events?
  • How do you monitor event-driven systems?
  • Kafka vs Event Bus?
  • How do you ensure reliable event publishing?
  • How do you maintain ordering?

Be prepared to explain not only the concepts but also the trade-offs between synchronous REST communication and asynchronous event-driven communication.

Quick Revision

  • Event-Driven Architecture enables asynchronous communication using events.
  • Events represent facts that have already occurred, while commands request actions.
  • Event brokers such as Kafka decouple producers and consumers.
  • Event Sourcing stores every state change as an event.
  • CQRS separates write and read models.
  • Saga manages distributed transactions using compensation.
  • The Outbox Pattern guarantees reliable event publishing.
  • Idempotent consumers prevent duplicate business processing.
  • Monitor event throughput, consumer lag, retries, and DLQs.
  • Combine Kafka, Saga, Outbox, CQRS, monitoring, and replay services to build scalable, resilient enterprise event-driven systems.