Event sourcing in HLD - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to identify the main component that stores all changes as events.

HLD

The core component in event sourcing that stores all changes is called the [1].

Drag options to blanks, or click blank then click option'

ADatabase

BEvent Store

CCache

DLoad Balancer

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing the event store with a regular database.

Thinking the cache stores all events.

The Event Store is the main component that records every change as an event in event sourcing.

2fill in blank

medium

Complete the code to describe the process that rebuilds the current state from events.

HLD

To get the current state, event sourcing uses a process called [1] which replays all events.

Drag options to blanks, or click blank then click option'

AEvent Replay

BSnapshotting

CCaching

DLoad Balancing

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing snapshotting with event replay.

Thinking caching rebuilds the state.

Event Replay is the process of applying all stored events to rebuild the current state.

3fill in blank

hard

Fix the error in the description of the event sourcing write process.

HLD

When a change happens, the system [1] the new state directly to the database.

Drag options to blanks, or click blank then click option'

Awrites

Bdeletes

Cstores events

Dcaches

Attempts:

3 left

💡 Hint

Common Mistakes

Assuming the system writes the new state directly.

Confusing storing events with caching.

In event sourcing, the system stores events representing changes, not the new state directly.

4fill in blank

hard

Fill both blanks to complete the event sourcing pattern description.

HLD

In event sourcing, the [1] records all changes as events, and the [2] rebuilds the current state by applying these events.

Drag options to blanks, or click blank then click option'

AEvent Store

BCache

CEvent Processor

DLoad Balancer

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing up the roles of event store and event processor.

Choosing cache or load balancer incorrectly.

The Event Store records all events, and the Event Processor applies them to rebuild state.

5fill in blank

hard

Fill all three blanks to complete the event sourcing write flow.

HLD

When a user action occurs, the system creates an [1], stores it in the [2], and then the [3] updates the read model.

Drag options to blanks, or click blank then click option'

AEvent

BEvent Store

CEvent Processor

DCache

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing the event with the read model.

Mixing up the event store and cache roles.

The system creates an Event, stores it in the Event Store, and the Event Processor updates the read model accordingly.

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