30 mins System Design Exercise: Payment Card Fraudulent Detection In Production System

Requirements and clarification. (Short version)

• Fraudulent prevention from online transactions.
• Pool of risky card info is provided through 3rd party service. Note, it only provides newly added fraudulent cards, not a general record of all the cards. 10k new cards added daily, each record have 20kb of data.
• Online transaction volume: 1 million transaction per day.
• When to check: user input information, pre-payment, actual transaction. There might be a gap between prepayment and actual transaction.
• Scalability, latency, reliability and throughput considerations.

First design draft to make sure functional requirements are met.

Polling service will call the 3rd party service to get a list of newly added fraudulent cards and store them in the database.

An fraudulent service will expose a GET API to accept queries for fraudulent check, and returns with either risky or not. It will take the encrypted payment card number and check the DB against it, if there is an entry, the card is fraudulent.

Confirm with interviewer if this is the right direction and if you have missed anything.

Second version with more detailed design and take none functional requirements into action.

1. Data collection services. Based on the traffic volume, a master and a standby service should be sufficient enough. For further scalability it can be a fully managed stateless cluster service.
2. DB choice. As it is read heavy, and the amount of writes are fairly small, SQL db is the choice, clustered index is optimised for read efficiency. Based on the volume of data stored: it will be constantly growing, as the system needs to maintain a copy of the records, the 3rd party service only provides newly added records. Sharded by consistent hashing, and can be replicated.
3. Message queue. It will update 3 sources of data: bloom filter, cache, and DB. The necessity for cache is debatable, you need to point out why do you think it is needed, my reason is it is optional, it should be depend on analytics and business cases: only if there is a pattern that newly added fraudulent card has a higher hit rate, a cache layer will be beneficial.
4. Bloom filter. It will certainly work well in this case given it is provide fast response if the searched item is definitely not in the storage. It will improve the response time to the fraudulent service.
5. Fraudulent services. Since it is stateless, it can easily be scaled out, I don't think message queue is necessary here, for yet next level scalability, an upfront load balancer will be enough.
6. Other considerations. Like cost per call to external services, auto scale up and down based on traffic volume, storage, which part of the system to be scaled down first, etc.

Handle additional requirements. What if we need to notify service consumers about the fraudulent cards after transaction taken place.

A service to run periodically and get transactions from last 2-4 weeks (configurable, based on analytics and business requirements) and cross check in the fraudulent service, identify and risky actions and notify the users through multiple channels.

Transaction service need to provide at least payment details and customer info for communication.

Final design.

Always remember, it is not just about technology, focus on the problem to solve with the resources you have. Provide reasoning for each decision.

Happy designing!