Bird
Raised Fist0

Event Sourcing and CQRS with Message Queues

HLDmediumInterview freq: medium
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/5
Command API Layer

Receives client command

Accepts HTTP REST command to update domain state

Protocol:HTTP/REST
BeforeClient has a new command to update data
AfterCommand API Layer received and forwarded command to Write Model
Write Model

Validates and processes command

Applies business rules and generates domain events

Protocol:Internal call
BeforeCommand received but not yet validated or processed
AfterDomain events produced and sent to Kafka event log
Kafka (Event Log)

Stores domain events

Appends events to durable, ordered event log

Protocol:Kafka Produce
BeforeNo new events in Kafka for this command
AfterEvents durably stored in Kafka with ordering guarantees
Read Model Workers

Consume events from Kafka

Reads events asynchronously and updates read model projections

Protocol:Kafka Consume
BeforeRead model projections are stale, missing latest events
AfterRead model projections updated with new event data
Query API Layer

Serves client query

Reads from updated read model projections to answer queries

Protocol:HTTP/REST
BeforeClient requests latest data via query
AfterClient receives up-to-date data from read model projections
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│   Command API Layer   │
└────────────┬──────────┘
             │ HTTP/REST
             ▼
┌───────────────────────┐
│      Write Model      │
│  (validates & stores) │
└────────────┬──────────┘
             │ Produce
             │ to Kafka
             ▼
┌───────────────────────────┐
│    Kafka (Event Log)      │
│  (durable ordered events) │
└────────────┬──────────────┘
             │ Consume
             │ events
             ▼
┌───────────────────────────┐
│    Read Model Workers     │
│ (update projections async)│
└────────────┬──────────────┘
             │ Update
             │ Read DB
             ▼
┌───────────────────────┐
│    Query API Layer    │
│ (serves read queries) │
└───────────────────────┘
Design Rationale

This architecture separates command processing and query handling using CQRS with event sourcing. The Command API Layer accepts client commands and forwards them to the Write Model, which validates and generates domain events. These events are durably stored in Kafka, ensuring ordered, reliable event logging. Read Model Workers asynchronously consume these events to update read-optimized projections, enabling fast queries. The Query API Layer serves client queries from these projections, decoupling reads from writes and improving scalability and responsiveness. This design ensures strong consistency for writes while allowing eventual consistency for reads, leveraging Kafka as the central event log.

Primary Focus

✓

Practice

(1/5)
1. If the Gossip Protocol component fails to propagate membership updates, what is the most immediate failure observed in the key-value store?
medium
A. Consistent hashing ring fails to rebalance keys on node failure
B. Nodes continue to send requests to failed nodes causing timeouts
C. Clients receive stale data due to vector clock version conflicts
D. Write operations block indefinitely waiting for quorum acknowledgments

Solution

  1. Step 1: Understand gossip failure impact

    Without membership updates, nodes are unaware of failed nodes and continue routing requests to them.

  2. Step 2: Eliminate other failure modes

    Vector clocks handle versioning, unrelated to gossip failure. Consistent hashing ring updates rely on membership info but do not fail immediately. Write blocking on quorum is unrelated to gossip propagation.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Missing membership updates cause requests to failed nodes causing timeouts [check]
Hint: Gossip failure -> nodes unaware of failures, keep sending requests [OK]
Common Mistakes:
2. For delivering notifications to mobile devices at 10M+ scale, which architecture better handles intermittent connectivity and battery constraints?
medium
A. Use push notification services (APNs, FCM) with message TTL and retries managed by the platform
B. Use persistent gRPC streaming connections from server to device for real-time delivery
C. Use long polling HTTP connections from device to server to fetch notifications
D. Use SMS as the primary delivery channel for all notifications

Solution

  1. Step 1: Evaluate persistent connection approaches

    gRPC streaming (A) is unreliable on mobile due to network changes and battery constraints; long polling (C) wastes battery and bandwidth.

  2. Step 2: Consider platform push services and SMS

    Push services (B) handle retries and offline buffering efficiently; SMS (D) is costly and not suitable for all notifications.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Platform push services manage retries and offline buffering [check]
Hint: Use platform push services, not persistent streams on mobile [check]
Common Mistakes:
3. For a high-throughput e-commerce platform requiring sortable, unique order IDs generated across multiple regions with minimal coordination, which ID generation approach is best?
medium
A. Use Twitter Snowflake-style custom IDs with timestamp and region bits
B. Use UUIDv4 generated randomly at each region
C. Use auto-increment IDs generated by a centralized database
D. Use auto-increment IDs generated independently per region without coordination

Solution

  1. Step 1: Identify requirements

    High throughput, sortable, unique IDs across regions with minimal coordination.

  2. Step 2: Evaluate options

    UUIDv4 (A) is unique but not sortable; centralized auto-increment (C) causes bottlenecks; independent auto-increment (D) risks collisions; Snowflake-style IDs (B) embed timestamp and region, enabling sortable, unique IDs with decentralized generation.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Snowflake IDs -> sortable, unique, decentralized [check]
Hint: Sortable unique IDs at scale -> Snowflake pattern [check]
Common Mistakes:
4. At 10x scale, which component is most likely to become the bottleneck first in the LLM-powered support bot, and why?
hard
A. The Intent Classifier service, due to synchronous LLM inference latency under high concurrency
B. The human agent pool, because fallback requests increase linearly with user queries
C. The message queue, because it cannot handle the increased throughput of fallback messages
D. The database storing user session states, due to write contention at scale

Solution

  1. Step 1: Identify scaling challenges for each component

    Human agents (A) scale linearly but can be increased with hiring. Message queue (C) scales well horizontally. Database (D) can be sharded.

  2. Step 2: Analyze Intent Classifier bottleneck

    Synchronous LLM inference is compute-intensive and latency-sensitive, causing concurrency limits and queuing delays at 10x load.

  3. Step 3: Confirm first failure point

    Intent Classifier service hits CPU/GPU resource limits first, blocking downstream components.

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    Synchronous LLM inference latency limits concurrency first [check]
Hint: LLM inference latency blocks concurrency at scale [check]
Common Mistakes:
5. At 10x scale, which component in WhatsApp's architecture is most likely to fail first and why?
hard
A. Chat Servers because WebSocket connections are stateful and cannot be resharded easily
B. Kafka brokers because partition count cannot be increased dynamically
C. The database because it cannot handle 10x more writes without sharding
D. Presence service because TTL cache invalidations become too frequent

Solution

  1. Step 1: Analyze stateful WebSocket connections on Chat Servers

    Chat Servers maintain in-memory state per WebSocket; scaling requires connection migration which is complex.

  2. Step 2: Compare other components

    Databases can shard; Kafka partitions can be increased with rebalancing; presence TTL cache scales horizontally.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Stateful WebSocket connections -> Chat Servers bottleneck at scale [check]
Hint: Stateful WebSocket -> Chat Servers bottleneck at 10x scale [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard