Store all domain changes as an immutable append-only sequence of events in an event store table. State is never updated in place — it is rehydrated by replaying all events for an aggregate. Aggregates apply each event to reconstruct their current state. Publish events to Kafka after appending to the store for downstream consumers.

Event store, aggregate rehydration, and append

Event sourcing design principles:

1
The event store is append-only — never update or delete events; they are the permanent record.
2
Aggregate state is derived by replaying events from the beginning of a stream.
3
Use snapshots for aggregates with long event histories — store a checkpoint every N events.
4
Publish events to Kafka after appending so projections and other services can subscribe.
5
Event sourcing pairs naturally with CQRS — the write model appends events; the read model builds projections.

Difficulty: 7/10

Topics: event sourcing, NestJS microservices, CQRS

Scenario Questions

0-2 years experience

1
Imagine you need to add a new command to an existing NestJS microservice that uses event sourcing. Walk me through the steps you’d take to record the event and update the read model.
2
If a message fails to be published to the event store in your NestJS microservice, what would happen to the transaction, and how would you handle the error?
3
How would you configure a NestJS microservice to connect to a Kafka topic that serves as your event store?

2-5 years experience

1
We have a user registration flow where the command service emits a UserCreated event, but the projection service isn’t reflecting the new user. What debugging steps would you take?
2
Explain the trade‑offs between storing events in a relational database versus an append‑only log like Kafka when using NestJS microservices.
3
During a deployment, you notice that replaying events to rebuild a read model takes much longer than expected. What design changes could you make to improve replay performance?

5-8 years experience

1
Design a strategy for handling schema evolution of events in a NestJS microservice architecture that must stay backward compatible.
2
How would you ensure exactly‑once processing of events across multiple NestJS microservice instances under high load?
3
Discuss how you would implement snapshotting in a NestJS event‑sourced system to keep aggregate reconstruction fast, and what pitfalls to watch for.

8+ years experience

1
Our organization wants to migrate a legacy monolith to an event‑sourced, NestJS microservice ecosystem. What high‑level migration plan would you propose, and how would you manage data consistency during the cut‑over?
2
When multiple teams own different bounded contexts that share events, how do you govern event contracts and versioning to avoid breaking changes across NestJS services?
3
At scale, what operational concerns (e.g., monitoring, replay, disaster recovery) arise with event sourcing in NestJS microservices, and how would you address them architecturally?

Follow-up Questions

❓How would you test the end‑to‑end flow of command to event to projection?
❓What metrics would you put in place to detect event processing lag?
❓Can you describe a fallback strategy if the event store becomes unavailable?