Event sourcing in HLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the primary benefit of using event sourcing in a system?

Consider a system that records all changes as events instead of just storing the current state. What is the main advantage of this approach?

A It allows rebuilding the current state by replaying all past events.

B It reduces the total number of database writes by storing only the latest state.

C It eliminates the need for backups since events are immutable.

D It automatically encrypts all data for security.

💡 Hint

Think about how you can recover or understand the system state at any point in time.

Event sourcing stores every change as an event, enabling the system to rebuild the current state by replaying these events. This provides a full history and audit trail.

❓ Architecture

intermediate

Which component is essential in an event sourcing architecture to reconstruct the current state?

In an event sourcing system, which component is responsible for rebuilding the current state from stored events?

A Event Store

B API Gateway

C Event Processor (or Event Replay Engine)

D Command Handler

💡 Hint

Think about the part that reads events and applies them to get the current state.

The Event Processor or Event Replay Engine reads stored events and applies them in order to reconstruct the current state of the system.

❓ scaling

advanced

How can event sourcing systems handle very large event streams efficiently?

When the number of events grows very large, replaying all events to rebuild state becomes slow. What is a common technique to improve performance?

A Use snapshots to store periodic full states and replay only recent events.

B Delete old events after a fixed time to keep the event store small.

C Store only the latest event and discard previous ones.

D Switch to a relational database to speed up queries.

💡 Hint

Think about saving intermediate states to avoid replaying everything from the start.

Snapshots capture the full state at a point in time, so the system only needs to replay events after the snapshot, improving rebuild speed.

❓ tradeoff

advanced

What is a key tradeoff when using event sourcing compared to traditional state storage?

Event sourcing offers benefits but also has downsides. Which of the following is a common tradeoff?

A Loss of historical data due to overwriting events.

B Increased complexity in rebuilding state and handling event versioning.

C Inability to audit changes since only current state is stored.

D Reduced fault tolerance because events are mutable.

💡 Hint

Consider what extra work developers must do when using event sourcing.

Event sourcing requires managing event versioning and rebuilding state from events, which adds complexity compared to storing only current state.

❓ estimation

expert

Estimate the storage growth for an event sourcing system with 1000 events per second over 1 year, assuming each event is 1 KB.

Calculate the approximate storage needed to keep all events for one year if the system generates 1000 events every second and each event is 1 KB in size.

A About 315 GB

B About 315 TB

C About 3.15 TB

D About 31.5 TB

💡 Hint

Calculate total seconds in a year, multiply by events per second and event size.

There are 31,536,000 seconds in a year. 1000 events/second * 1 KB/event * 31,536,000 seconds = 31,536,000,000 KB = ~31.5 TB.

Practice

1. What is the main idea behind event sourcing in system design?

easy

A. Store all changes as a sequence of events to reconstruct state

B. Store only the latest snapshot of data for quick access

C. Use events only for logging errors in the system

D. Send events to users as notifications without storing them

Solution

1. Step 1: Understand event sourcing concept

   Event sourcing means saving every change as an event, not just the final data.

2. Step 2: Identify how state is managed

   The current state is rebuilt by applying all stored events in order, not by snapshots alone.

3. Final Answer:

   Store all changes as a sequence of events to reconstruct state -> Option A

4. Quick Check:

   Event sourcing = store events to rebuild state [OK]

Hint: Event sourcing saves changes as events, not just snapshots [OK]

Common Mistakes:

• Confusing event sourcing with snapshot-only storage
• Thinking events are only for error logs
• Believing events are just notifications

2. Which of the following is the correct way to represent an event in an event sourcing system?

easy

A. { "eventType": "UserCreated", "timestamp": "2024-06-01T12:00:00Z", "data": { "userId": 123 } }

B. [ "UserCreated", 123, "2024-06-01" ]

C. "UserCreated: userId=123 at 2024-06-01"

D. CREATE USER 123 AT 2024-06-01

Solution

1. Step 1: Identify proper event structure

   Events should be structured data with type, timestamp, and data fields for clarity and processing.

2. Step 2: Compare options

   { "eventType": "UserCreated", "timestamp": "2024-06-01T12:00:00Z", "data": { "userId": 123 } } uses a clear JSON object with eventType, timestamp, and data, which is standard practice.

3. Final Answer:

   { "eventType": "UserCreated", "timestamp": "2024-06-01T12:00:00Z", "data": { "userId": 123 } } -> Option A

4. Quick Check:

   Event = structured JSON with type and data [OK]

Hint: Events are structured objects with type, timestamp, and data [OK]

Common Mistakes:

• Using unstructured strings for events
• Confusing event data with SQL commands
• Using arrays without keys for event details

3. Given these events in order:
[{"eventType":"AddItem","data":{"itemId":1}}, {"eventType":"AddItem","data":{"itemId":2}}, {"eventType":"RemoveItem","data":{"itemId":1}}]
What is the final state of the item list?

medium

A. [1, 2]

B. [2]

C. [1]

D. []

Solution

1. Step 1: Apply events in order to the item list

   Start with empty list. Add item 1 -> [1]. Add item 2 -> [1, 2]. Remove item 1 -> [2].

2. Step 2: Determine final list content

   After all events, only item 2 remains in the list.

3. Final Answer:

   [2] -> Option B

4. Quick Check:

   Apply events sequentially = final list [2] [OK]

Hint: Apply events one by one to get final state [OK]

Common Mistakes:

• Ignoring remove event
• Applying events out of order
• Assuming all added items remain

4. You notice that replaying all events to rebuild state is very slow. What is a common solution to improve performance in event sourcing?

medium

A. Store only the latest event for each entity

B. Delete old events after 1 day to reduce size

C. Use snapshots to save intermediate states periodically

D. Switch to storing only current state, no events

Solution

1. Step 1: Identify performance issue cause

   Replaying all events from the start can be slow as event count grows.

2. Step 2: Choose common optimization

   Snapshots save the full state at points in time, so replay starts from snapshot, reducing replay time.

3. Final Answer:

   Use snapshots to save intermediate states periodically -> Option C

4. Quick Check:

   Snapshots speed up event replay [OK]

Hint: Use snapshots to avoid replaying all events every time [OK]

Common Mistakes:

• Deleting events breaks history and audit
• Keeping only latest event loses full history
• Abandoning events loses event sourcing benefits

5. You design an event sourcing system for a bank. Which approach best ensures data consistency and auditability when multiple transactions happen concurrently?

hard

A. Process events in random order to improve throughput

B. Allow events to overwrite each other without checks for speed

C. Store only final balances without event history to simplify design

D. Use optimistic concurrency control with event versioning and conflict detection

Solution

1. Step 1: Understand concurrency challenges in event sourcing

   Concurrent transactions can cause conflicts if events overwrite each other or are applied out of order.

2. Step 2: Choose method to maintain consistency and audit

   Optimistic concurrency control uses event version numbers to detect conflicts and prevent overwrites, preserving history and correctness.

3. Final Answer:

   Use optimistic concurrency control with event versioning and conflict detection -> Option D

4. Quick Check:

   Optimistic concurrency = safe concurrent event handling [OK]

Hint: Use versioning to detect conflicts in concurrent events [OK]

Common Mistakes:

• Ignoring conflicts causes data corruption
• Dropping event history loses audit trail
• Processing events unordered breaks state correctness