Donation System
Topic: Donation System
Interviewer: nicky
Interviewee: smoothe
Level: L4 (Experienced Individual Contributor)
Topic
Mock System Design Interview Summary
Interview Overview
Date: 12/12/2021
Target level:
Duration: 1 hour
Topic covered: Donation
Drawing tool used: micro.com
Requirements
Functional requirements
Donate money while ordering food, (during holiday season)
The donated money is sent to charity
Review donation recipients, review their goals. Drop down menu / no need for search
User can choose a target donee from a list of donees
User can create an order to donate money
User can track their donation order status
System will generate big amount alert before they place the order
Non goals:
How the UI in the app
3rd party payment gateway already exists
Non functional requirements
Availability > consistency
Ballpark calculation
Daily active users 3M customers, 6M in peak
3 million new order placed everyday, 3M / 3600 = 1667 QPS -> 2k QPS
12 * 10^6 * 1KB = 12GB per day
12GB * 5 * 365 = 21900GB for 5 years
System Design
External APIs
API gateway
SSL encryption
Load balancing
User -> API gateway -> order service -> orderDB
|-> kafka -> worker pool -> 3rd party payment gateway
Payment status change
-> update order DB
Order service can send notification to user
Stakeholder ->
Background service order history DB -> doneeID
User part:
createOrder(userID, apitoken, doneeID, amount, payment method)
Response: alert, orderID
POST API
userID, doneeID, amount, 10th order -> backend will generate a unique orderUUID
Q: Handling of idempotency: if the frontend sends a payment, but disconnects from the backend
A:
Backend successfully insert but acknowledgment was not sent back to the frontend
Backend did not insert
checkOrderStatus(userID, apiToken, orderUUID)
Get API
Response: status
System design diagram
Database schema
orderDB (SQL - guarantee transaction):
orderUUID, donorID, doneeID, amount, created_timestamp, update_timestamp,
orderStatus(created, pending, complete/reject)
orderHistoryDB for each doneeID -> for the summary part
orderUUID, donarID, amount, timestamp
Donee table -> for the money part
Additional design
How do we scale up the service?
Order service can scale horizontally
A lot of users need to get the list of charities to donate to. How do we handle the high-throughput?
List of donees are static. They can be put in a configuration service
Interviewee: How often do we need to update the donee list?
Interviewer: can tolerate some delay
Interviewer: How do we scale up the orderDB?
Interviewee: mysql can be sharded by orderUUID
Interviewer: Read heavy or write heavy?
Interviewee: Read
Interviewer: how to deploy it geographically?
Interviewee: depends on requirement.
Interviewer: how many masters?
Interviewee:
For high availability 1 master
For consistency: x masters
If consistency < availability: 1 master
If availability > consistency: ? masters
Discussions during the Interview
Interviewer and Audience Feedback after the Interview
Interviewer:
Reasonably good across the board
Since this does not cover payment gateway, so the complexity is reasonably low.
Gathered requirement with reasonable pace
API, data model, reasonably straightforward
Well handled additional requirement for metrics reporting
Idempotent - deep dived, can handle detailed questions
Broke it down into detailed scenarios, 加分
Small CRM system to manage donees
SQL/NoSQL
availability / consistency: seemed to have reversed
Application is more suited for SQL
But it may not be the same reason as you mentioned. NoSQL is different from distributed database. Not all NoSQL are distributed.
SQL is stronger for transactional.
SQL is stronger than NoSQL ACID support
It’s good: Static file deploy to frontend. Usually was answered by adding cache
For simple and slow changing items, we can use simpler method like you mentioned
Use of database hook is good to trigger updates
Multi-region support:
Database model, leader/follower model - is safe choice
Multi-region deployment: 2 master or 1 master?
Globally 1 master, others are followers, then it will slow down writes. Usually the master fails then a slave will become master
Globally 2 masters (across regions), others are followers, then there may be consistency challenge. If there are conflicts in the writes, then hard to auto-resolve
Follow up:
How do we handle refunds?
24 hour: customer can change the amount
Social media sharing to twitter
How many came through the twitter/social shares
Audience: Interviewer: hire or strong hire?
Data center may be the main point for improvement?
The requirement is relatively simple because payment is already handled
If it’s for L5, it may be complex.
One time transaction, recurring transaction
Every month donate $10
Small amount of payment. Some payment service will consolidate multiple transactions into one big transaction.
It’s an unusual question
Audience:
junior: hire
Senior: no hire - higher expectation
Should ask more from product manager
For example, donation - may calculate by the end of the month
Some technical questions may be solved by requirement changes
Error handling, fail-over
When will talk about 3rd party system
- some 3rd party may not be able to handle big transaction volume
Requirement: somewhat too long
45 minutes - 1 hour
Requirement clarification - API, tables, deep dive
How to control the time
Biggest problem is interviewee may not be able to use the time efficiently and clarify
Audience:
May have spent too much time in the parameter
The drawing is small
Debrief
Audience
Design REST API: just a facade. No need to deepdive
Database schema: should be a focus. How to make it extensible
Some candidate may go off track such as auth (usually auth is not the focus)
REST API may not be the focus
GraphQL vs REST. There may be bonus for GraphQL
Audience
Can you draw a diagram ahead of time?
Probably not, except interviews that are similar to homework
Audience:
Would the interviewer has a focus?
Usually yes. Usually database design, business requirements, distributed system
Audience:
Infrastructure. What will be the focus?
Audience:
Discuss requirement may waste time
We have 1,2,3,4,5. Which one do you want to go through
Ask the interviewer which one is the emphasis
Listing the options is usually short
Some interviewers are specific
Some interviewers are open - they need the interviewees to narrow it down
Core scenarios
Listing too many features may be too much
For open questions, we must list it.
Audience
Time estimate - may not be worth it
100k seconds
Audience
Usually they don’t use the numbers
We may want to put it to later
Audience
L5 - traffic size, database size,
Every day several G -> it may impact the design choices
Audience:
Calculation will impact whether to use distributed vs single node
It impacts the
1000QPS -> must use distributed system
< 1000QPS -> can use single
What business to handle
Are there 3rd party dependency
Synchronous vs non-synchronous
Audience
QPS < 1000
QPS > 1000-10000
1T-100T
We probably can
Maintenance of data in the future
It may impact later decisions
1 minute can cover estimation
A new question:
the most difficult is to know what metrics are important for the business
May want to
If people are using template - will not lose point
We should emphasize how to prepare for this question
Should list all the assumptions
Audience:
API / architecture
Create Order -> order ID
Did not know the payment is successful
orderUUID -> will probably
Not very user friendly
Don’t want the donation block the order
Donation can be put into the queue
Main order is processed
Payment is much later
Order are processed asynchronously
$10 guarantee - somebody guarantees
Audience:
Ideally payment can be processed at the same time
You may be able to change the order within 24 hours
Place order -> Pending state -> 2-3 days later becomes paid
Synchronization across regions have high delay
Cassandra: east cluster, west cluster.
Often the sync is slow and has problem
Financial: Oracle
Multi-zone