Bird
Raised Fist0

Design a Digital Wallet System - Double-Entry Ledger, Consistency, Reconciliation

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/5
API Gateway

Receive transfer request

Accepts user request to transfer funds between wallets

Protocol:HTTP/REST
BeforeUser has initiated a transfer request on client device
AfterAPI Gateway has validated and forwarded request to Transaction Coordinator
Transaction Coordinator

Start transaction and produce events

Creates debit and credit events for double-entry ledger

Protocol:Kafka
BeforeNo transaction events exist for this transfer
AfterDebit and credit events are published to Kafka topic
Kafka Cluster

Persist transaction events

Stores events durably and guarantees ordering per transaction

Protocol:Kafka
BeforeKafka topic does not contain events for this transaction
AfterKafka topic contains ordered debit and credit events
Ledger Service (Cassandra)

Consume events and update ledger

Applies debit and credit entries atomically to ledger database

Protocol:Kafka Consumer
BeforeLedger database in Cassandra does not reflect this transaction
AfterLedger database in Cassandra updated with consistent double-entry records
Reconciliation Service

Verify ledger consistency

Periodically scans ledger entries to detect mismatches or errors

Protocol:HTTP/REST
BeforeLedger entries exist but have not been recently verified
AfterReconciliation confirms ledger consistency or flags anomalies
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  API Gateway  │
└───────┬───────┘
        │ HTTP/REST
        ▼
┌───────────────────────────┐
│  Transaction Coordinator  │
└───────┬───────────┬───────┘
        │ Kafka     │ HTTP/REST
        ▼           ▼
┌───────────────┐  ┌───────────────────────┐
│ Kafka Cluster │  │ Reconciliation Service │
└───────┬───────┘  └─────────┬─────────────┘
        │ Kafka Topic            │ HTTP/REST
        ▼                      ▼
┌───────────────────────────────┐
│ Ledger Service (Cassandra)    │
└───────────────────────────────┘
Design Rationale

This architecture ensures strong consistency for a digital wallet by using a double-entry ledger pattern. The API Gateway receives user requests and forwards them to the Transaction Coordinator, which orchestrates the creation of debit and credit events. These events are durably stored and ordered in the Kafka Cluster, ensuring reliable event sourcing. The Ledger Service consumes these events and atomically updates the Cassandra-backed ledger, maintaining consistency. The Reconciliation Service periodically verifies ledger integrity to detect any discrepancies, enabling robust error detection and correction. This design balances durability, ordering, and consistency critical for financial transactions.

Primary Focus

✓

Practice

(1/5)
1. In the hotel booking system, at step 4 of the reservation flow, the Inventory Service checks room availability. What state does the Inventory Service report if the room was reserved moments ago but the Reservation Service has not yet confirmed the booking?
easy
A. The room is marked as available because the reservation is not yet confirmed
B. The room is marked as temporarily unavailable due to a pending reservation lock
C. The room is marked as unavailable only after payment confirmation
D. The room availability status is unknown until the Reservation Service sends a confirmation event

Solution

  1. Step 1: Trace Inventory Service state at step 4

    The Inventory Service relies on confirmed reservation events to update availability. Pending reservations may not yet be reflected.

  2. Step 2: Understand event-driven state updates

    Without confirmation, Inventory cannot mark the room as unavailable. It waits for Reservation Service confirmation events to update state, so availability is unknown until then.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Inventory waits for confirmation events before updating availability [check]
Hint: Inventory updates only after confirmed reservation events [check]
Common Mistakes:
2. In a Cassandra-based messaging system, at step 4 the coordinator node receives a write request for a message with partition key user123. What happens if the coordinator node's local replica is down?
easy
A. The coordinator immediately fails the write request with an error
B. The coordinator writes to a backup relational database instead
C. The coordinator routes the write to other replicas responsible for user123's partition
D. The coordinator retries the write on the same node until it recovers

Solution

  1. Step 1: Understand coordinator role in Cassandra write path

    The coordinator routes writes to all replicas responsible for the partition key; if one replica is down, it routes to the others.

  2. Step 2: Evaluate failure handling

    Writes are not failed immediately if a replica is down; coordinator does not retry indefinitely on the same node; no fallback to relational DB.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Coordinator routes writes to available replicas -> ensures write availability [check]
Hint: Coordinator routes writes to live replicas, not fail immediately [check]
Common Mistakes:
3. For handling concurrent seat bookings, which architecture better suits a high-traffic ticketing system requiring low latency and strong consistency?
medium
A. Use a centralized relational database with serializable transactions to lock seats
B. Use client-side seat locking with server-side eventual consistency checks
C. Use a message queue to serialize all booking requests for each seat
D. Use a distributed cache with optimistic locking and retry logic for seat reservation

Solution

  1. Step 1: Analyze concurrency and latency requirements

    High traffic and low latency require minimizing blocking and centralized bottlenecks.

  2. Step 2: Evaluate architectures

    Centralized DB serializable transactions cause contention and latency; message queue serialization adds delay; client-side locking is unreliable. Distributed cache with optimistic locking allows concurrent attempts with retries, balancing consistency and performance.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Optimistic locking in distributed cache balances concurrency and consistency [check]
Hint: Optimistic locking + retry beats centralized locks under load [OK]
Common Mistakes:
4. Without the distributed consensus component (e.g., Raft), what exact failure occurs during a primary node crash in GitHub's database cluster?
medium
A. Primary node continues accepting writes, causing split-brain and data divergence
B. Backup snapshots fail to trigger, preventing recovery from crash
C. Failover blocks indefinitely waiting for leader election, causing downtime
D. Clients experience immediate failover with stale data reads

Solution

  1. Step 1: Role of consensus in failover

    Consensus prevents split-brain by ensuring only one leader accepts writes.

  2. Step 2: Consequence of missing consensus

    Without consensus, multiple nodes may accept writes simultaneously, causing data divergence.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Consensus absence leads to split-brain and inconsistent writes [check]
Hint: No consensus -> split-brain and data divergence
Common Mistakes:
5. A team must decide between using a detailed blame-focused report or a blameless timeline with action items for their post-mortem. Which approach is best for fostering continuous improvement in a high-trust engineering culture?
medium
A. Use blameless timelines with actionable steps to encourage learning and improvement
B. Use blame-focused reports to enforce accountability and prevent future errors
C. Use only automated logs without human analysis to avoid bias
D. Skip post-mortems entirely to save time and avoid conflict

Solution

  1. Step 1: Evaluate cultural impact of blame vs blameless approaches

    Blame-focused reports create fear and reduce openness, harming continuous improvement.

  2. Step 2: Assess effectiveness of blameless timelines with action items

    They foster trust, encourage learning, and drive actionable improvements aligned with high-trust culture.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Blameless + action items -> continuous improvement [check]
Hint: Blameless + action items build trust and improve systems [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