Target Level:
Mid to Lead Developer
Expected Duration:
1-2 hours
Goals
determine overall knowledge of different software components
databases (sql, nosql)
messaging systems (queues, topics)
APIs
determine knowledge of architectural/coding patterns
determine ability to communicate reasons for decisions
Problem Description:
Design a payments system.
You are tasked to create a payments system that manages the entire lifecycle of a payment. The user will deposit money via the payments system, which should be reflected on their account balance upon success. The payment system will integrate to multiple different external payment provider, and each provider exposes their API in different ways. The system will determine which payment provider to use for the payment by checking multiple fields: currency, customer country, amount, and payment method.
Requirements:
payments system is only accessible to users with accounts
Users should not know which provider is used:
they will only input the currency, amount, and payment method
Supported payment methods:
Card (credit card/debit card)
EWallet
Bank Transfer
Keeps track of payment lifecycle:
status of payment can be tracked
payment history of the user should be accessible
can accommodate additional providers
account balance must be updated correctly upon success payment
Alternative Scenarios:
external merchants process each payment synchronously (i.e. they return the result immediately after called)
easier scenario
might be better as a starting point, or for non-leads
can introduce asynchronous processes afterwards (i.e. merchant returns but with pending, and will notify us if the process is done)
Follow-up/Guiding questions:
How would you store merchant specific info
e.g. merchant id, username, password, etc
e.g. merchant related settings such as currencies allowed, countries allow, amount limits, etc
How to handle a large amount of concurrent transactions
How to handle long running processes
How durable is the system
how to handle errors within services
how to handle failures from merchant side
how to handle duplicate requests
How to secure the system
e.g. if the merchant calls a callback url, how would you handle that?
Database:
what db would you use?
Which services would have a db?
describe the tables/schema
describe how you would design the API
grpc/rest/graphql
describe how it would look like
describe the class structure for one of the services
can ask the applicant to actually code the class the handles the how to determine the merchant to use
describe alternate solutions, and the trade-offs for using that over the current design
Attachments:
design-problem-payments-system (application/vnd.jgraph.mxfile)
~design-problem-payments-system.tmp (application/vnd.jgraph.mxfile)