Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

In our payment system, there are a few things we need to store:

User metadata and relevant user information
Users' account information
Idempotent keys for user transactions
Detailed logs of all deposit/transfer transactions

To store these data, we want to use a relational database.

Relational database have strong ACID properties. In our use case, we need strict serializability.
Users, accounts etc. can be represented by relational data models. We might need to run cross-join queries which relational database is optimized for.

The tradeoff is higher horizontal scaling complexity, and we can't easily support high throughput. Also, the data schema is not as flexible as a document database. However, this is an acceptable tradeoff given the most critical feature is consistency.

Here's some sample data models:

table users {

user_id: UUID,

user_name: String,

user_email: String,

user_phone_number: String,

user_address: String,

user_mailing_address: String,

user_accounts: List<UUID>,

user_type: String,

}

table accounts {

account_id: UUID,

account_owner: UUID,

account_status: String,

account_opened_at: Timestamp,

account_balance: Double,

account_currency: String,

account_type: String,

account_metadata: String,

}

table transactions {

transaction_user: UUID,

transaction_target: UUID,

transaction_type: String,

transaction_amount: Double,

transaction_status: String,

transaction_time: Timestamp,

transaction_metadata: String,

tr

}

For any queries to deposit and transfer, we will have to make cross account updates an atomic operation. Either all succeed, or complete rollback. It will be like:

BEGIN TX; UPDATE accounts SET balance = balance - 100 WHERE id = sender; -- debit UPDATE accounts SET balance = balance + 100 WHERE id = recipient; -- credit INSERT INTO ledger (txn_id, from, to, amount, ts); -- the record COMMIT;

Once the data size becomes larger, we will need to shard the database. We will shard the users table by user_id, and shard the accounts table by account_owner_id, so accounts for the same user are in the same database shard. For transfer between each database shard, we will need to use 2 phase-commits between shards.

To ensure data durability and availability, we also need to create replicas for each shard. However, we do need to use synchronous replications across replicas, so we won't have different replicas returning different values.

All requests to the service go through API gateway and load balancers. API gateway does rate limiting and authentication. Load balancers do request distribution through consistent hashing of user_id.

For any transfers between accounts, or deposits and credits:

We query the relational database, and query accounts that are involved, get their associated metadata.
We create an idempotent key and store it in the idempotent key cache. For retries, we check whether the previous request with same key succeeded. If so, we reject the retry request.
We query the fraud detection service, which uses an ML model to determine whether the account is at risk of fraud. If so, we reject the request.
We trigger the external payment provider, and tries to trigger the transfer/deposit. Upon success, we use an atomic operation to update the relevant account balances TOGETHER with the ledger. In case of failures, we retry with idempotent keys.
We also send a request to the notification service, which updates the client in case of any transaction completion.

For viewing account details:

We query the relational database, and retrieve account metadata for a user.

To ensure strict serializability, all transactions on the ledger are sorted by timestamp. To address clock skew, we use NTP servers to sync time across servers.

There is the problem of high request volume for corporate accounts:

A merchant receiving 10K TPS on one account → all traffic hits one shard, one row, one lock. Throughput collapses. Three standard solutions:

Sub-wallets: split the corporate account into 10 buckets, distribute ops round-robin. Parallelizes the row locks. Cost: reads must aggregate, and per-bucket overdraft checks get fuzzy — usually fine for credits into a merchant account.
Per-account sequencer + batching: a queue per account, one consumer applies ops in ordered batches. A burst of 5,000 small credits becomes one aggregated DB write. This is how real processors (Stripe's ledger, PayPal) handle merchant volume.
Dedicated shard for hot accounts: detect and move them — acknowledges the problem rather than solving it.

To achieve 99.9% availability, for non-critical services like notification service, we make them fail-open. If requests are overwhelming the database, instead of failing everything, we trigger load shedding on the database, as well as implement circuit breakers on the caller side.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10