Each test is 5 questions with varying difficulty.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.
Event Sourcing and Command Query Responsibility Segregation (CQRS) represent an advanced architectural paradigm shift from traditional CRUD-based state management. In 2026, these patterns are critical for high-scale, distributed systems where auditability, temporal querying, and extreme write throughput are non-negotiable. Event Sourcing persists the state of a system as a sequence of immutable events, while CQRS decouples the write model (commands) from the read model (queries). These patterns are frequently required for roles in FinTech, logistics, and large-scale microservices platforms. Interviewers focus on these topics to gauge a candidate's ability to handle distributed system complexities, such as eventual consistency, transaction boundaries, and state reconstruction. Junior engineers are expected to understand the basic flow of events and the separation of concerns, while senior engineers must demonstrate expertise in handling event schema evolution, projection lag, and the trade-offs between strong and eventual consistency in production.
The shift toward Event Sourcing and CQRS is driven by the need for systems that provide a perfect audit trail and the ability to 'time travel' by replaying events. In 2026, as AI-driven systems require high-fidelity data lineage for training and debugging, the ability to reconstruct state from immutable logs is a competitive advantage. Engineering teams at companies like Uber or Stripe rely on these patterns to handle millions of transactions per second without locking contention. This topic is a high-signal interview subject because it forces candidates to move beyond standard database-per-service thinking. A strong answer reveals a deep understanding of how to manage state in a distributed environment, the implications of asynchronous processing, and how to design systems that are inherently resilient to failure. Weak answers often fail to account for the operational overhead of managing projections or the complexity of handling event versioning, which are the most common failure points in real-world implementations.
The architecture operates by decoupling the write-side (Command) from the read-side (Query). Commands are validated against the current aggregate state, resulting in events that are persisted to an immutable Event Store. These events are then published to a message bus, where multiple projectors consume them to update materialized views optimized for specific query requirements.
[Client Request]
↓
[Command Handler]
↓
[Aggregate]
↓
[Event Store]
↓
[Event Bus]
↓ ↓
[Projector] [Projector]
↓ ↓
[Read DB] [Search Index]
↓
[Client Query]Centralizing state changes through a single entity that manages internal consistency and event generation.
Trade-offs: Ensures consistency but can limit concurrency if the aggregate is too large.
Writing events to a local database table within the same transaction as the command state change, then using a relay to publish to the bus.
Trade-offs: Guarantees at-least-once delivery but requires a relay process.
Clearing and re-running all events from the store to recreate a read model from scratch.
Trade-offs: Allows schema evolution but is resource-intensive and slow for large streams.
| Reliability | Use the Outbox Pattern to ensure atomic writes between the command store and the event bus. |
| Scalability | Scale read models horizontally by adding more projectors or read replicas. |
| Performance | Use snapshotting to bound the time required to reconstruct aggregate state. |
| Cost | Storage costs for events grow indefinitely; implement archival strategies for old streams. |
| Security | Encrypt sensitive event data at rest and use fine-grained access control for event streams. |
| Monitoring | Track 'Projection Lag' (time difference between event occurrence and read model update). |
No. While both involve recording events, Event Sourcing uses these events as the primary source of truth to reconstruct application state. A log is typically an auxiliary artifact for debugging or auditing, whereas in Event Sourcing, if the event is lost, the state is lost.
No. You can implement CQRS with a traditional relational database by having a write model and a separate read model. However, Event Sourcing and CQRS are frequently used together because Event Sourcing provides a natural way to feed the read-side projections.
You can use techniques like optimistic UI updates, where the client assumes success, or by using version tokens that allow the client to poll until the read model reflects the command's effect. You should also provide clear feedback to the user when an action is pending.
The biggest risk is operational complexity. Managing event versioning, projection lag, and the infrastructure for replaying events requires a high level of engineering maturity. It is not a pattern to be adopted without a clear business need for auditability or complex state management.
Yes, you can. Many production systems use PostgreSQL as an event store by creating an 'events' table with columns for aggregate ID, version, and payload. However, specialized databases like EventStoreDB offer features like stream-based projections and better performance for high-throughput event streams.
You cannot delete immutable events. To handle GDPR or privacy requirements, you must use 'crypto-shredding,' where you encrypt the sensitive data in the event payload with a unique key. Deleting the key effectively makes the data unreadable, satisfying the 'right to be forgotten'.
A command is an intent to change state (e.g., 'PlaceOrder'), which can be rejected. An event is a statement of fact that has already occurred (e.g., 'OrderPlaced'). Commands are processed; events are recorded.
You build a dedicated read model (projection) specifically for reporting. This model can be a flattened SQL table, a search index, or a graph database, optimized for the specific queries your reporting dashboard requires, rather than trying to query the raw event stream.
Avoid it for simple CRUD applications where the overhead of managing event streams and projections outweighs the benefits. If your business domain does not require a perfect audit trail or complex state transitions, traditional CRUD will be significantly more maintainable and performant.
Use snapshotting. By saving the state of an aggregate every N events, you can load the latest snapshot and only replay the events that occurred after the snapshot, significantly reducing the time and memory required to reconstruct the aggregate.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.