Amazon system design mock interview (with Senior SWE)

GET 1-to-1 COACHING for system design interviews: app.igotanoffer.com/en/interv...
Today's mock interview is with an ex-Amazon Senior SWE. Tim tackles the question: "Design a phone billing system"
Book a coaching session withTim here: app.igotanoffer.com/coaching/...
(he's an expert in C, C++, Java, Python, Assembler)
Chapters:
00:00 Intro
01:09 Question
01:20 Clarifications (functional requirements)
06:30 Clarifications (non-functional requirements)
13:20 Components
17:05 High level architecture
23:52 Databases
34:30 Drill down (core billing services)
41:33 Conclusion
43:20 Availability
45:54 Security
48:01 Final feedback
48:40 End of interview
About us:
IGotAnOffer is the leading career coaching marketplace ambitious professionals turn to for help at high-stakes moments in their career. Get a job, negotiate your salary, get a promotion, plan your next career steps - we've got you covered whenever you need us.
Come and find us: igotanoffer.com/

[@MaxingMix]

For the database, alternatively one could use columnar database, which enables fast aggregation and a have good storage size (due to the nature of columnar db).
You'll partition the phone calls by month, and then order it by phone number and date time.
And additionally if the fee is different for different time of the day, you can compute the cost on each call and save it there.
This will enable generating the bill real time, which is useful to avoid heavy compute workload and enables user to see the bill before end of the month

[@aldogutierrezalcala3047]

What about using eventual cosistency here? I mean, some sort of data streaming like kafka to process all calls from customers so you can scale if needed depending on the producer/consumers. Consumers can basically process each call and add it to another database using MySQL (or RDBMS) to easily aggregate the calls by month (or billing period).
I decide to use Kafka since the same topic can be used for another consumer to, let's say, analytics for the customer or even the company.
I think having a single entry point of processing call, may become a bottle neck.

[@deathbombs]

29:20 I like how he handles the data mining and parallel processing more easily by sharding, and the billing service is sharded too to match it , so each worker can split the shards

[@dmitryd3605]

Great stuff. I'd say though using off the bat integration via shared database tightly couples Call Control Framework with the Billing Service, it is often being frowned upon. There are benefits for such integration: in case Billing Service generates bills once a month, Call Control Framework guys have a chance to fix records before bill is generated. Though I would seriously consider queueing data.

[@ninadkavimandan7040]

I really liked how well Tim introduced each component whilst stating the responsibility, and then stitching them all together. Great video! What software/app do you use for drawing?

[@chases4951]

If there are 500M calls per day, I think we would expect around 15B calls per month instead of 1.5.

[@mohammadtoficmohammad3594]

thanks very useful video and good software design

[@IGotAnOffer-Engineering]

Thanks Mohammad, glad you like the video.

[@cooldudecs]

You wouldn’t want to use a queue. You would want an event streaming bus like Kafka . Kafka will retain the message if failures happen. A plain queue will not. I’m also assuming he is crunching aggregations on each customer at the end of the month. He will have to do so for each number associated with a customer. It can be quick or brutal depending a customer being a big corporations. We need a daily aggregator to insert updated keys in a key store with number hashed -> billing numbers. He then would check for phone numbers. In each service as it aggregates a much easier additive number. Once bills are calculated a notification to the user via a queue. It can broad cast to all comm services

[@aldogutierrezalcala3047]

Good to know that I see this message on a similar approach I suggested!

[@IGotAnOffer-Engineering]

Get 1-on-1 system design interview coaching from Tim or other ex-FAANG interviewers: app.igotanoffer.com/en/interview-coaching/type/system-design-interview/

[@user-gm9yp5jn5v]

Which tool are you using to do the system design on?

[@IGotAnOffer-Engineering]

If I remember rightly, Tim's using Excalidraw :)

[@kdakan]

To me, this is not a good design. Some improvements I have in mind:1) A phone bill is created for each individual phone number, not for individual customer, so partition key could be different. 2) Calls are bounced between different phone operators, caller's operator does the billing but sometimes the fee is calculated based on the operator on the other side of the call. Fees also differ on different days and hours, so there is no single fee per call duration. 3) Bills do not need to be calculated at the end of the billing period, Computation task can be done after each call is made, then the billing service just needs to aggravate the already computed date. This will free up the computing bottleneck. This also allows us to not store every call information on the live database, which will grow huge. We just need to store the billable calls that is not gone through the billing job, any other call or the computed calls can move to a cold archive db immediately. So, my design would be a queue consumer that computes the feee after each call and moves the call data to the archive db and inserts the fee per call in a temporary db, and a map-reduce job run at the end of the billing period to aggregate the computed data into a bill, and remove the call fee data from the temporary db.

[@kdakan]

@@mohammadtoficmohammad3594 Who's your 'dear'? I'm suggesting a different design if you read it full. You should do more than that if you're to design a system or pass an interview to the least.

[@loinsrch]

Great feedback and valid points, kdakan! Please consider this video an example of how to approach an interview design problem in a structured manner leveraging the background, domain knowledge, and ideas you bring to the interview on that day rather than the incontrovertibly best possible answer to this particular question. I'd encourage viewers to consider my design critically and contribute ideas here on how it could or should be improved (or even make your own video!).

[@kdakan]

@@loinsrch I understand this is a new channel and these videos are somewhat geared towards engagement from viewers. Thanks for the info.

[@freezefrancis]

@kdakan totally agree, I was thinking in the same direction of using queues, hadoop/spark map-reduce jobs etc which looks a good fit for this case

[@mohammadtoficmohammad3594]

kdakan your design is not good , we can not calculate the bill after each call , thats will be huge load on the system , to call the temp database , save the result in temp db ,move old data to archive db , delete the old from the tmp db , all that on every call.