Event-Driven Architecture, CQRS, Event Sourcing, Sharding & Idempotency — Interview Questions

How to use this lesson

These are "powerful but costly" patterns. Senior answers explain when not to use them, and how to operate them: schema evolution, replay, reconciliation, monitoring.

Q1. What is event-driven architecture, and when is it a good fit?

Short answer: In EDA, components communicate by producing and reacting to events: immutable facts about something that happened (OrderPlaced, PaymentFailed), usually through a broker or log (Kafka, RabbitMQ, EventBridge). Producers don't know their consumers. The styles:

• event notification (thin events; consumers call back for details);
• event-carried state transfer (the events carry the data, so consumers keep local copies);
• event sourcing (Q3);
• choreographed sagas.

It's a good fit for:

• decoupling teams and services (new consumers added without changing the producer);
• asynchronous workflows and long-running processes;
• spiky loads (buffering);
• real-time reactions and streaming analytics;
• integrating many systems (CDC);
• audit trails.

It's a poor fit when you need immediate, strongly consistent responses across services, for simple CRUD systems, or when the team lacks observability and operational maturity (debugging event chains is harder). Essentials: schema governance, idempotency, ordering by key, DLQs, tracing and replay.

Learn it in depth → Event-Driven Architecture Patterns

Q2. What is CQRS? What are its trade-offs?

Short answer: Command Query Responsibility Segregation means separate models (and often separate stores) for writes (commands) and reads (queries):

• the write model enforces the business rules and invariants (normalised, transactional, aggregate-based);
• the read models are denormalised projections optimised for specific queries (a search index, dashboard tables, a Redis cache), updated asynchronously from events or CDC.

The benefits:

• independent scaling and optimisation of reads and writes;
• simpler complex queries;
• several read models for different consumers;
• a natural fit with event sourcing, and with microservice data composition.

The trade-offs:

• eventual consistency between writes and reads (users may not see their own changes immediately, so you need read-your-writes techniques);
• more moving parts (projections, sync pipelines, replay and rebuild tooling);
• duplicated data;
• more complex debugging.

Use it where the read and write workloads differ significantly in shape or scale, not for every CRUD screen. You can apply it selectively, per bounded context.

Learn it in depth → CQRS Basics

Q3. What is event sourcing? What are the challenges of implementing it?

Short answer: Event sourcing stores an entity's state as an append-only sequence of events (AccountOpened, MoneyDeposited, MoneyWithdrawn), instead of the current state. The current state is derived by replaying the events (with snapshots for performance). The benefits:

• a complete audit history, with temporal queries ("what was the balance on June 1?");
• the ability to rebuild or add read models by replaying;
• natural event publication;
• debugging by replaying production histories.

The challenges:

• Event schema evolution: the events are stored forever, so you need upcasters or versioned events, and must never break the old ones.
• Querying: you need CQRS read models (you can't just query the current state).
• Eventual consistency of the projections, and rebuild times for large streams (snapshots, parallel projections).
• Concurrency control: optimistic versioning per stream (expected version on append).
• Deleting or correcting data (GDPR: crypto-shredding, or tombstone events; mistakes are corrected with compensating events, not edits).
• A learning curve, and tooling (EventStoreDB, Axon Server, Kafka as a log plus a snapshot store; Marten for .NET).
• Over-application: use it only for domains where the history matters (finance, ledgers, compliance-heavy workflows), not everywhere.

Q4. How do you implement database sharding?

Short answer:

1. Choose the shard key: high cardinality, even distribution, present in most queries, and keeping related data together (tenant ID, customer ID). Avoid monotonic keys (hotspots).
2. Choose the strategy:
   • hash-based (even distribution; range queries across shards suffer);
   • range-based (efficient ranges; hotspot risk);
   • directory or lookup-based (flexible placement: a tenant → shard map, and you can move tenants);
   • geo-based (data residency).
3. Routing:
   • an application-level router (a routing DataSource keyed by the shard key);
   • a proxy (Vitess for MySQL, Citus for Postgres, ShardingSphere);
   • or a database with native sharding (MongoDB, Cassandra, CockroachDB, Spanner).
4. Use many logical shards on fewer physical nodes (for example 1,024 logical shards), so rebalancing moves whole logical shards, not rows. Or use consistent hashing.
5. Handle the cross-shard concerns:
   • avoid cross-shard joins (denormalise, or use scatter-gather for rare queries, or a separate analytics store);
   • avoid cross-shard transactions (sagas);
   • globally unique IDs (Snowflake-style, ULID or UUIDv7);
   • global secondary indexes (maintained asynchronously).
6. Operations: resharding tooling, backups per shard, monitoring for hot shards, and schema migrations across all shards.

Rule: exhaust vertical scaling, replicas, partitioning and caching first. Sharding is a one-way door, with high complexity.

Learn it in depth → Database Sharding

Q5. How do you implement idempotent APIs?

Short answer:

• Use naturally idempotent methods where possible: PUT (full replace), DELETE, and PUT with a client-generated ID for creation.
• For POST (payments, orders), use an idempotency key:
  1. the client sends an Idempotency-Key (a UUID) per logical operation, and reuses it on retries;
  2. the server stores (key, client or tenant, request hash, status, response, created_at), with a unique constraint. This is inserted atomically before or with the business operation (in the same transaction, or with a status of IN_PROGRESS);
  3. on a repeat with a completed status, return the stored response (the same status and body);
  4. concurrent duplicates (IN_PROGRESS) get 409, or wait;
  5. the same key with a different payload gets 422;
  6. apply a TTL (for example 24 hours) and clean-up.
• Downstream: pass the idempotency keys to providers (Stripe and others support them), and make consumers idempotent (an inbox table).
• Business-level uniqueness: unique constraints on natural keys (an external order reference) as the final safety net.

@Transactional
public OrderResponse create(String idemKey, CreateOrderRequest req) {
    var existing = idempotency.find(idemKey);
    if (existing.isPresent()) {
        var rec = existing.get();
        if (!rec.requestHash().equals(hash(req))) throw new IdempotencyKeyMismatchException();
        return rec.response();                                   // replay the original result
    }
    idempotency.insertInProgress(idemKey, hash(req));            // a unique constraint blocks concurrent twins
    OrderResponse resp = orders.place(req);
    idempotency.complete(idemKey, resp);
    return resp;
}

Learn it in depth → Payment — Idempotency Implementation

Q6. What is back-pressure, and how do you implement it in a service?

Short answer: Back-pressure means a slower downstream signals an upstream to slow down, instead of being overwhelmed (unbounded queues, then OOMs and cascading timeouts). The implementations:

• Bounded queues and pools: executors with bounded queues plus a rejection policy (CallerRunsPolicy slows the producers), and bounded in-memory buffers.
• Load shedding at the edge: return 429 or 503 with Retry-After when the concurrency or queue limits are hit (Resilience4j bulkheads or rate limiters, concurrency limiters like Netflix's adaptive concurrency limits).
• Reactive streams: request(n) demand in Reactor or WebFlux, and limitRate, overflow strategies.
• Messaging: the pull-based consumers (Kafka) consume at their own pace, pause or resume partitions when downstream is saturated, and use RabbitMQ prefetch limits. The broker absorbs bursts, and lag becomes the visible pressure signal for autoscaling.
• TCP flow control and HTTP/2 stream windows, at the transport level.
• Adaptive client behaviour: retries with backoff and jitter, retry budgets, and circuit breakers.

The goal is graceful degradation: the system serves what it can at its capacity, and says no quickly to the rest.

Follow-up questions this topic invites — and their answers

Q: What's the difference between an event and a command? A: A command expresses intent, and targets one handler, which may reject it (PlaceOrder). An event states a fact that already happened, and may have many (or no) subscribers (OrderPlaced). Commands are named in the imperative; events in the past tense.

Q: How do you rebuild a CQRS read model? A: Deploy a new projection version that consumes from the beginning of the event log (or a snapshot plus the log), into a new table or index. When it has caught up, switch reads to it (an alias or feature flag), then drop the old one. This is why retention and replay capability matter.

Q: Do you need Kafka for event sourcing? A: No, and Kafka is often a poor event store on its own (no per-aggregate optimistic concurrency, and awkward per-entity reads). Use a proper event store (EventStoreDB, Axon Server, or a Postgres events table with a stream version constraint), and publish to Kafka for integration.

Q: What is the "outbox + CDC" combination good for? A: Reliable event publication. The business change and the event commit atomically in one database transaction, and CDC (Debezium) streams the outbox to Kafka with low latency, and no polling load. It solves the dual-write problem.