Bird
Raised Fist0

Design a Payment System - Transaction Processing, Idempotency, Settlement

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

Receives payment request

Accepts HTTP POST /pay with payment details

Protocol:HTTP REST
BeforeClient has payment data ready to send
AfterPayment request forwarded to Payment Service
Payment Service

Checks idempotency

Queries Idempotency Store to detect duplicate request ID

Protocol:Redis GET
BeforePayment request received, idempotency unknown
AfterIdempotency Store confirms request is new or duplicate
Idempotency Store (Redis Cluster)

Returns idempotency status

Returns whether request ID exists; sets new ID if absent

Protocol:Redis GET/SET
BeforeRequest ID not yet checked or stored
AfterRequest ID stored to prevent duplicates
Payment Service

Stores transaction record

Writes transaction data to Transaction DB with strong consistency

Protocol:SQL (CockroachDB)
BeforeIdempotency confirmed, transaction not stored
AfterTransaction record durably stored in DB
Settlement Service

Processes settlement

Fetches transactions from DB and sends settlement requests to banks

Protocol:gRPC to DB, HTTPS to External Banks
BeforeTransactions stored but not settled
AfterSettlement requests sent to External Banks
External Banks

Confirms settlement

Processes settlement and returns confirmation

Protocol:HTTPS API
BeforeSettlement request received
AfterSettlement confirmed, funds transferred
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────┐
│   API Gateway     │
└─────────┬─────────┘
          │ HTTP/REST POST /pay
          ▼
┌───────────────────┐
│  Payment Service  │
│ - Validate input  │
│ - Check idempotency│
└───────┬───────────┘
        │ Redis GET/SET
        ▼
┌───────────────────────────┐
│ Idempotency Store         │
│ (Redis Cluster)           │
└─────────────┬─────────────┘
              │
              │
              ▼
┌───────────────────────────┐
│ Transaction DB            │
│ (CockroachDB)             │
│ - Store transaction record│
└─────────────┬─────────────┘
              │
              │ gRPC
              ▼
┌───────────────────┐
│ Settlement Service │
│ - Batch settlements│
│ - Communicate with │
│   External Banks   │
└─────────┬─────────┘
          │ HTTPS API
          ▼
┌───────────────────┐
│  External Banks   │
└───────────────────┘
Design Rationale

This Payment System architecture ensures reliable transaction processing with idempotency and settlement. The API Gateway receives client requests and forwards them to the Payment Service, which first checks the Idempotency Store (Redis Cluster) to avoid duplicate processing. If the request is new, the Payment Service stores the transaction in the strongly consistent Transaction DB (CockroachDB). The Settlement Service later batches these transactions and communicates with External Banks over HTTPS to settle funds. This design separates concerns: idempotency caching for quick duplicate detection, durable storage for transactional integrity, and asynchronous settlement with external systems, ensuring fault tolerance and consistency across components.

Primary Focus

✓

Practice

(1/5)
1. In a consistent hashing system, at Step 4 the request router receives a key and queries the hash ring to find the responsible shard. What happens if the shard mapped by the hash ring is currently down?
easy
A. The router retries the same shard until it recovers before forwarding the request
B. The router uses the next clockwise shard on the hash ring as a fallback for the key
C. The router returns an error immediately to the client indicating shard unavailability
D. The router hashes the key again with a different hash function to find another shard

Solution

  1. Step 1: Trace request router behavior on shard failure

    Retrying the same shard (The router retries the same shard until it recovers before forwarding the request) blocks requests; returning error (The router returns an error immediately to the client indicating shard unavailability) reduces availability; next clockwise shard (The router uses the next clockwise shard on the hash ring as a fallback for the key) is correct only if the ring is intact and shard failure is handled by virtual nodes.

  2. Step 2: Understand fallback hashing

    Rehashing with a different function (The router hashes the key again with a different hash function to find another shard) is a common fallback to find an alternate shard when the primary is down, ensuring availability without blocking or errors.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Fallback hashing finds alternate shard on failure [check]
Hint: Fallback hashing finds alternate shard if primary is down [OK]
Common Mistakes:
2. A video calling system must establish peer-to-peer connections between clients behind NATs and firewalls. Which component is primarily responsible for enabling this connectivity?
easy
A. STUN/TURN servers that assist in NAT traversal and relay when direct connection fails
B. Media Server that relays all media streams to bypass NAT restrictions
C. Signaling Server that encodes and decodes media streams for transmission
D. WebRTC client library that manages user authentication and session persistence

Solution

  1. Step 1: Identify NAT traversal role

    STUN/TURN servers help clients discover public IPs and relay media if direct peer-to-peer fails.

  2. Step 2: Eliminate other components

    Media Server relays media but is not primarily for NAT traversal; Signaling Server handles session negotiation, not media encoding; WebRTC client manages connection but relies on STUN/TURN for NAT traversal.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    STUN/TURN enable NAT traversal, essential for peer connectivity [check]
Hint: STUN/TURN servers enable NAT traversal and relay fallback [check]
Common Mistakes:
3. In a time-series ingestion pipeline, at step 4 the Aggregation Worker reads raw event batches from Kafka and writes summarized metrics to the time-series database. What happens if the Aggregation Worker crashes after reading but before writing?
easy
A. The raw events remain in Kafka and will be reprocessed after worker restart
B. The Aggregation Worker automatically retries writing without re-reading events
C. The summarized metrics are partially written causing data corruption in the database
D. The raw events are lost because Kafka deletes them immediately after consumption

Solution

  1. Step 1: Understand Kafka's offset commit behavior

    Kafka retains messages until consumers commit offsets. If the worker crashes before committing, messages remain available for reprocessing.

  2. Step 2: Analyze crash timing

    Since the worker crashed before writing summaries and committing offsets, raw events remain in Kafka and will be reprocessed after restart.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Kafka retains uncommitted messages for reprocessing [check]
Hint: Kafka commits offsets after processing to avoid data loss [check]
Common Mistakes:
4. Without the retry queue component, what exactly breaks in the webhook delivery system when a subscriber's endpoint is temporarily unreachable?
medium
A. The system immediately drops the event, causing permanent loss
B. The Delivery Worker blocks sending other events to that subscriber until recovery
C. The event is lost silently, and the subscriber never receives it
D. The system continues sending events out of order, violating ordering guarantees

Solution

  1. Step 1: Understand retry queue role

    The retry queue buffers failed deliveries to preserve order by retrying later.

  2. Step 2: Trace failure without retry queue

    Without it, subsequent events may be sent immediately, causing out-of-order delivery.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    No retry queue -> out-of-order delivery possible [check]
Hint: No retry queue -> ordering breaks on failures [check]
Common Mistakes:
5. At 10x scale, which MongoDB component is most likely to become the bottleneck first when using the bucket pattern for time-series data, and why?
hard
A. The application server, because it cannot generate bucket IDs fast enough for writes.
B. The MongoDB query router (mongos), because it must maintain metadata for all buckets and route writes precisely.
C. The shard servers, because bucket documents grow large and cause frequent document splits and index overhead.
D. The network layer, because increased bucket writes saturate bandwidth between shards.

Solution

  1. Step 1: Identify bucket pattern scaling challenges

    Bucket pattern creates many bucket documents requiring precise routing by mongos.

  2. Step 2: Mongos metadata overhead

    Mongos maintains routing metadata and must route each write to correct shard and bucket, increasing load at scale.

  3. Step 3: Compare other components

    Shard servers handle writes but document splits are less frequent; network saturates later; app server bottleneck unlikely.

  4. Final Answer:

    Option B -> Option B

  5. Quick Check:

    Mongos routing metadata load grows fastest at 10x scale [check]
Hint: Mongos routing metadata overload is first bottleneck at 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