Loading...
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
The business has set a target to acquire 100,000 users. Assume they may reach and exceed this target. We will safely support 10x this number. So target daily active users is 1,000,000.
The system will have relatively few write endpoints: namely on-boarding and transfer of money. There will be relatively many read endpoints e.g. balance, transfer history, payees, settings, cards and accounts. Assume users will check their balance often. On-boarding may require many writes, but is a one off process. Assume 1 write for every 3 reads.
Assume the following entities: user, payee, card, accounts, settings, transaction. Assume 1 user will have 10 payees, 2 cards, 2 accounts, 1 settings, and 1 new transaction per day. Assume each entity has 10 columns of type nvarchar(100) that is 2 bytes per character. Over a year that's (1,000,000 users + 10,000,000 payees + 2,000,000 cards + 2,000,000 accounts + 1,000,000 settings + 365,000,000 transactions) * 10 columns * 100 characters * 2 bytes = 730,016,000,000 bytes of data in a year = 730 GB of data in a year maximum. If we reach our target exactly then around 73 GB of data in a year.
Transactions will be 1,000,000 users * 1 transaction per day / 24 / 60 / 60 = 12 TPS. Assume peak periods might result in up to 10x that load meaning 120 TPS.
Assume 10% of users active concurrently = 100,000 active sessions at once. During peak periods assume 50% or 500,000 active sesssions.
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
Onboarding:
Payments:
Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.
Client
Web application that acts as client.
IDP
Manage user accounts and facilitate login.
BFF
Stateless API that responds to client requests and co-ordinates communication between back-end services.
KYC Service
Accepts customer identity documents and validates.
Payments Gateway
3rd party service that handles actual payments.
Event Streaming
Event streaming platform allows us to respond to events from 3rd party services e.g. payment state transitions.
Database
Allows storage of core entities and updating state.
Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...
User
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
Payment Idempotency
When requesting a payment we will require an idempotency key to ensure that no duplicate messages are ever processed. The client will generate a unique key when detecting user intent to pay e.g. tapping a "Pay Someone" button. That key travels through the entire user experience until submitting the payment. It only changes if the user cancels the user experience. This key comes in with the payment request and is inserted into either cache or DB. If there is already a row for that key then the payment is not sent for processing.
Saga
One a payment request is received and idempotency key does not exist, it can be sent to the payment gateway. This moves the payment into it's first state. Events are emitted for subsequent states and picked up by a worker process. The worker updates the payment state in the cache/db so the UI can react.