Bird
Raised Fist0

Design a Payment Gateway like Razorpay or Stripe - Architecture, Webhook, Retry

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

Receives payment request

Accepts HTTPS POST from client and validates request format

Protocol:HTTPS
BeforeClient has payment details ready to send
AfterAPI Gateway has validated and forwarded request to Payment Service
Payment Service

Checks idempotency key

Queries Redis to verify if request ID was processed before

Protocol:Redis GET
BeforePayment Service has incoming request with idempotency key
AfterIdempotency Store confirms request is new or duplicate
Idempotency Store (Redis)

Stores new idempotency key

Sets key with TTL to prevent duplicate processing

Protocol:Redis SET
BeforeIdempotency Store does not have this request ID
AfterIdempotency Store caches request ID with expiry
Transaction DB (Cassandra)

Persists transaction record

Inserts payment details and status into Cassandra

Protocol:CQL INSERT
BeforeTransaction DB lacks this payment record
AfterTransaction DB durably stores payment transaction
Event Stream (Kafka)

Publishes payment event

Emits event for downstream processing and webhook triggering

Protocol:Kafka PRODUCE
BeforeKafka topic does not have this payment event
AfterKafka topic contains new payment event
Webhook Worker

Consumes event and sends webhook

Reads event from Kafka and calls external webhook endpoint

Protocol:Kafka CONSUME + HTTP POST
BeforeWebhook Worker idle, no event processed
AfterWebhook Worker sent notification, retries on failure
🏗️
Architecture Diagram
Architecture Diagram
┌─────────┐
│ Client  │
└────┬────┘
     │ HTTPS POST /pay
     ▼
┌─────────────┐
│ API Gateway │
└────┬────────┘
     │ gRPC call
     ▼
┌───────────────┐
│ Payment Svc   │
│ (idempotency) │
└────┬──────────┘
     │ Redis GET/SET
     ▼
┌───────────────────────┐
│ Idempotency Store (Redis)│
└────┬───────────────────┘
     │ CQL INSERT
     ▼
┌────────────────────────┐
│ Transaction DB (Cassandra)│
└────┬───────────────────┘
     │ Kafka PRODUCE
     ▼
┌─────────────────────┐
│ Event Stream (Kafka) │
└────┬────────────────┘
     │ Kafka CONSUME
     ▼
┌───────────────┐
│ Webhook Worker│
└───────────────┘
Design Rationale

This Payment Gateway architecture handles client payment requests through an API Gateway that validates and forwards them to the Payment Service. The Payment Service enforces idempotency by consulting the Redis-based Idempotency Store to avoid duplicate processing. Once confirmed new, the payment details are durably stored in Apache Cassandra. The system then emits payment events to an Apache Kafka event stream, enabling asynchronous processing. The Webhook Worker consumes these events to notify external systems of payment status changes, implementing retries for reliability. This design ensures durability, idempotency, and scalable asynchronous notification handling.

Primary Focus

✓

Practice

(1/5)
1. A company needs to store large amounts of unstructured data like images and videos with metadata accessible via HTTP APIs. Which storage type best fits this use case?
easy
A. Object storage, because it stores data as objects with metadata and supports HTTP access.
B. Block storage, because it provides low-latency random access to raw data blocks.
C. File storage, because it offers hierarchical directories and POSIX file system semantics.
D. In-memory storage, because it offers the fastest access to large files.

Solution

  1. Step 1: Identify storage needs for unstructured data with metadata

    Object storage stores data as objects with customizable metadata and supports HTTP APIs, ideal for images/videos.

  2. Step 2: Eliminate other storage types

    Block storage is low-level and lacks metadata support; file storage is optimized for hierarchical file systems but less scalable for massive unstructured data; in-memory storage is volatile and unsuitable for large persistent files.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Object storage = scalable unstructured data + metadata + HTTP [check]
Hint: Object storage = objects + metadata + HTTP access [check]
Common Mistakes:
2. In the Snowflake ID generation flow, at Step 3 the sequence number is incremented after the timestamp and machine ID are set. What happens if the sequence number exceeds its maximum value within the same millisecond?
easy
A. The generator blocks and waits until the next millisecond to reset the sequence number.
B. The system resets the sequence to zero and continues generating IDs immediately.
C. The sequence number wraps around causing duplicate IDs within the same millisecond.
D. The machine ID is incremented to avoid sequence overflow.

Solution

  1. Step 1: Understand sequence number role in Snowflake

    The sequence number differentiates IDs generated within the same millisecond on the same machine.

  2. Step 2: Analyze overflow handling

    If the sequence exceeds its max (e.g., 4095), the generator must wait for the next millisecond to avoid duplicates. Resetting immediately (A) risks duplicates; wrapping (C) causes collisions; incrementing machine ID (D) is not part of the design.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Sequence overflow -> wait next millisecond to avoid duplicates [check]
Hint: Sequence overflow blocks until next millisecond [OK]
Common Mistakes:
3. For a chat application requiring low latency message delivery but tolerating occasional message loss, which architecture best balances latency and throughput?
medium
A. Use a batch processing system that aggregates messages every 5 seconds
B. Use a synchronous request-response system with guaranteed delivery acknowledgments
C. Use an asynchronous message queue with at-least-once delivery and eventual consistency
D. Use a distributed cache with write-through persistence for all messages

Solution

  1. Step 1: Analyze latency vs throughput needs

    Batch processing adds latency but can increase throughput and tolerate some message loss.

  2. Step 2: Evaluate architectures

    Synchronous (A) increases latency; asynchronous queue (B) reduces latency but may cause duplicates; distributed cache (D) lacks delivery guarantees; batch (C) balances throughput with acceptable latency for some use cases.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Batching trades latency for throughput, tolerating some loss [check]
Hint: Batching trades latency for throughput and tolerates loss [check]
Common Mistakes:
4. At 10x scale, which component of a Bloom filter system is most likely to fail first and why?
hard
A. The client application, due to increased latency in membership queries
B. The bit array storage, because increased insertions cause saturation and higher false positive rates
C. The hash functions, because their computation time grows linearly with scale
D. The network bandwidth, due to Bloom filter synchronization overhead

Solution

  1. Step 1: Identify scaling impact on Bloom filter components

    At very high scale, hash function computation cost increases linearly with insertions, becoming a CPU bottleneck.

  2. Step 2: Evaluate other components

    Bit array saturation affects false positives but does not cause immediate failure; network and client latency scale better.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Hash function CPU cost grows linearly, causing first failure at scale [check]
Hint: Hash function CPU cost grows linearly at scale [check]
Common Mistakes:
5. At 10x scale, which component in the Ticket Server pattern is most likely to become the bottleneck first, and why?
hard
A. Ticket Server, because it handles all block allocations and cannot be sharded easily
B. Clients, because local ID block exhaustion causes frequent server requests
C. Network, because increased traffic saturates bandwidth between clients and server
D. Database storing allocated blocks, because it cannot handle concurrent writes at scale

Solution

  1. Step 1: Identify centralization bottleneck

    The Ticket Server centrally allocates ID blocks and maintains allocation state, limiting horizontal scaling.

  2. Step 2: Compare other components

    Clients scale horizontally; network scales with infrastructure; database load is less critical if Ticket Server caches state.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Ticket Server centralization -> first bottleneck at 10x scale [check]
Hint: Central Ticket Server state limits horizontal scaling first [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