System design for dummies — part 3 (Design a donation app)

S. G.
4 min readFeb 7, 2022

This is the final part of a 4 part series on cracking the system design interview. Part 0 provided an overview of this article series, part 1 focused on the content you need to master to nail the interview and part 2 focused on the format you should follow during your system design interview.

In this final part I’ll provide a real life example of a system design problem — designing a donation app. I lifted this problem from this discussion on Leetcode. Here is the problem statement:

  • You are required to design a donation app for a 3 day charity event across the US where you are expecting 3 million donations.
  • You should accept details like customer name, credit card details etc.
  • No pay specific knowledge is required (presume that you’d integrate with a 3rd party pay provider like Stripe or Braintree).

If you are a visual learner like me & prefer videos to words, you can skip ahead to watching the video (it’s listed at the bottom of this post) and then come back to the article. I do recommend reading through the entire article as it covers some key concepts that I didn’t cover in the video.

Understanding requirements/goals

Focus on understanding the requirements to establish the bounds of the problem. Focus on the functional requirements (these would typically be specified in a PRD) as well as the non functional requirements.

For functional requirements, some of the questions you can ask are — Will the users be logged in? Will they be using an app? What’s the user experience if the payment fails or succeeds? Can the user view their past donations?

Note that if you are a senior candidate, you are expected to own the problem & it’s preferable that you come up with your own assumptions rather than expecting the interviewer to define constraints for you.

For this problem, I’ve chosen to focus on donations and largely ignored how details about the charity are surfaced in the app.

The non-functional requirements will typically help establish the bounds/constraints of the problem. Use back of the envelope calculations to get the RPS (requests per second). 3…

S. G.

I write about programming, people management, interviews or anything else that I’m obsessing about. 12+ yes of experience across big tech and some in academia.