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.png (image/png)
design-problem-payments-system (application/vnd.jgraph.mxfile)
~design-problem-payments-system.tmp (application/vnd.jgraph.mxfile)