Microservices Event Driven Architecture Interview Questions and Answers

Event-driven architecture is where microservices stop calling each other and start reacting to each other, and interviews use it to test whether you can reason about decoupling, delivery guarantees, and eventual consistency without getting lost. It also opens the door to the advanced patterns — event sourcing and CQRS — that separate mid-level from senior answers. This page covers the event-driven questions asked in interviews and the follow-ups that expose real understanding.

What is event-driven architecture, and why use it?

Services communicate by publishing and consuming events through a broker (Kafka, RabbitMQ) instead of calling each other directly — a service announces a fact and any interested service reacts. The benefit is decoupling in both time and knowledge: the producer neither waits for nor knows about its consumers.

This decoupling is what makes the system resilient and extensible. If a new service needs to react to orders, it just subscribes — no change to the order service. And if a consumer is down, events wait in the broker rather than causing the producer to fail, which structurally avoids the cascading failures that plague synchronous chains.

What is the difference between an event and a command?

An event is a fact about the past ('OrderPlaced') broadcast with no expected response — many consumers may react. A command is a directed request to do something ('ReserveInventory') aimed at a single handler expected to perform it. Events describe; commands instruct.

The distinction shapes coupling. Events invert the dependency — the publisher does not know who listens — giving maximum decoupling. Commands still target a specific service, so they couple sender to receiver more tightly. Choosing between them is a design decision interviewers like to probe.

What delivery guarantees exist, and why is exactly-once delivery a myth?

At-most-once (may lose messages), at-least-once (may duplicate, never loses — the practical default), and the idea of exactly-once. Exactly-once delivery is impossible across an unreliable network because the sender cannot distinguish a lost message from a lost acknowledgment. So systems deliver at-least-once and make processing effectively exactly-once via idempotency.

This is a classic separator. The right framing is: you accept duplicates at the transport layer and neutralize them at the application layer with idempotent consumers. Kafka's transactional/exactly-once features achieve this within Kafka's own boundaries, but the general principle still holds at service edges.

How do you build an idempotent consumer?

Give each event a unique ID and record processed IDs, so reprocessing the same event is a no-op — or design the operation so applying it twice equals applying it once.

@KafkaListener(topics = "orders")
public void onOrderPlaced(OrderEvent event) {
    if (!processedEvents.markIfNew(event.getId())) {
        return;                       // duplicate delivery — ignore
    }
    inventory.reserve(event.getOrderId(), event.getItems());
}

markIfNew atomically records the ID and reports whether it was already seen. Without this, a broker redelivery double-reserves inventory. Idempotency is the single most important habit in event-driven systems.

How do you publish an event and update the database atomically?

Use the transactional outbox pattern: write the event to an outbox table in the same local transaction as the business change, then a separate relay (often via change-data-capture) reads the outbox and publishes to the broker. This removes the dual-write problem.

The dual-write problem is subtle and interview-worthy: if you write to the database and then publish to Kafka as two steps, a crash between them either loses the event or, with naive retries, duplicates the write. The outbox makes the database write and the event's intent atomic, and the relay guarantees the event eventually reaches the broker.

Interview note: Follow-up: "why not just publish inside the transaction?" Because the broker is not part of the database transaction — a commit to the DB cannot atomically include a network send. The outbox turns the send into a local row write that is part of the transaction.

What is event sourcing?

Instead of storing current state, you store the ordered log of events that produced it, and derive current state by replaying them. The event log becomes the source of truth, giving a complete audit trail and the ability to reconstruct any past state.

The costs are real: replaying a long history is expensive (so you take periodic snapshots), and evolving event schemas over years is hard because you can never delete old events. Event sourcing is powerful for domains that need auditability, but it is not a default — mention the complexity, not just the appeal.

What is CQRS and when is it justified?

Command Query Responsibility Segregation splits the write model (optimized for consistency and updates) from the read model (optimized for queries), typically syncing the read side from events. Use it when read and write workloads diverge sharply or you need several query-optimized views of the same data.

CQRS pairs naturally with event sourcing — events update denormalized read models — but the two are independent. The trade-off is eventual consistency between write and read sides and more moving parts, so you adopt it for a specific pressure, not by reflex.

Interview note: Trap: "use CQRS everywhere for scalability." Over-applying CQRS adds consistency lag and complexity to simple CRUD that never needed it. Justify it with a concrete read/write mismatch.

How do you handle a bad (poison) message?

Retry a configurable number of times, then route the message to a dead-letter queue for inspection instead of blocking the partition, and alert so someone can investigate. A poison message that is retried forever stalls all messages behind it.

Ordering and partitioning also come up here: Kafka guarantees order within a partition, so events that must be processed in order share a partition key — but that limits parallelism, another trade-off to name.

What interviewers really test

Event-driven questions check whether you can think in terms of facts, decoupling, and eventual consistency, and whether you respect the realities of delivery — duplicates, poison messages, the dual-write problem. Strong candidates volunteer idempotency and the outbox pattern and treat event sourcing and CQRS as tools with costs, not silver bullets. Be ready to trace one event from publish to consumption, including the failure paths.

Event-driven architecture is the asynchronous half of the communication questions and the substrate the saga pattern question set runs on — pair this page with both. Build the underlying model with the microservices learning path, and rehearse tracing an event end to end in a mock interview.