Loading...
1 user can view event list, search event with keywords
2 user can book a ticket of particular event
3 if book success, user have to pay in 5 minutes
4 user receive a notification after the payment is succeed
5 Assume all tickets are the same
CAP:
partition tolerance is a must.
Strong consistency because it's related to money.
Tolerant lower availability.
Latency:
Consider all tickets sold out in 10s. Millions users conpeting the tickets. Support low latency to purchase a ticket
scalability
Using a microservice architecture makes sure that the app can be scaled horizontally.
There's 100 ongoing event every day.
Each event has 10k tickets in average.
Book Tps = 10K * 100 / 86400s = 11
Peak:
Hot event
1 million users are competing for the tickets, and the ticket is sold out in 10s.
write Tps 1million / 10s = 100k in peak.
user keep flushing the page before the event is availalble.
user flush page every second.
read qps 1million in peak.
storage
100 events every day, 100k tickets every events
1KB for ticket, order, payment info in total.
10 * 10k * 1KB *365 = 36.5G/year
considering read replica, 36.5G * 3 = 110G
api/v1/Event/view
request {eventId}
response
{
eventId
desc
ticketNum
price
detail
}
api/v1/order/create
request {userId, paymentInfo, eventId}
response {statusCode, error}
api/v1/order/view
request {userId, orderId}
response
{
{
orderId
status
detail
}
}
api/v1/payment/
request {userId, orderId, paymentInfo}
response {statusCode}
api/v1/payment/callBack
request {orderId, statusCode}
response {}
Event
{
id int
desc char(100)
ticketTotal int
ticketNum int
tickePrice int
updateTime timestamp
}
Order
{
id int
orderId int
detail int
status int
createTime timestamp
updateTime timestamp
}
User
{
id int
name char(20)
profile char(512)
Email char(64)
Phone int
paymentInfo char(512)
}
Event Service
Order Service
Payment Service
Notification Service
Order flow:
0 User send order request
1 User call order service, Order service deduct products
2 Order Service create order in DB, send a delay message to kafka, delay 10 minutes to consume
3 payment service receive result, call order service, update order status
4 after 10 minutes, consume the cancel event, check order DB status, if it's unpaid or pay failed status, cancel the order.
Payment flow
0 user call api gateway
1 api gateway route request to payment service.
2 Payment service call 3rd sdk(stripe, paypal, visa)
3 3rd sdk call payment service, return payment result
4 payment service receive result, call order service, update order status
Concurrency:
transaction: avoid dead lock, 2 or more transactions waiting forever. Use mysql, support acid
Consistency: User paid the order which is just canceled?
User immediate flush the page after payment
Explain any trade offs you have made and why you made certain tech choices...
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?