Donation System

December 12, 2021 7:00 PM PST

---

This document summarizes a mock system design interview focused on a donation system integrated with food ordering. The system allows users to donate money to charities while placing food orders, providing a seamless experience during the holiday season. The discussion covers functional and non-functional requirements, system design, database schema, and various technical considerations.

Requirements

Functional Requirements

• Users can donate money while ordering food.
• Donations are sent to selected charities.
• Users can review donation recipients and their goals via a dropdown menu.
• Users can choose a target donee from a list.
• Users can create an order to donate money.
• Users can track the status of their donation orders.
• The system generates alerts for large donation amounts before order placement.

Non-Functional Requirements

• Availability is prioritized over consistency.
• Estimated daily active users: 3 million, with peaks of 6 million.
• Average of 3 million new orders placed daily, equating to approximately 2,000 queries per second (QPS).
• Estimated data storage needs: 12GB per day, leading to about 21,900GB over five years.

System Design

External APIs

• API Gateway
• SSL Encryption
• Load Balancing

User Flow

• User -> API Gateway -> Order Service -> Order Database
• Order Service communicates with a worker pool and a third-party payment gateway for payment processing.
• Payment status changes update the order database.
• Notifications are sent to users regarding their orders.

API Endpoints

• Create Order:

  • Endpoint: createOrder(userID, apiToken, doneeID, amount, paymentMethod)
  • Response: Alert and orderID.

• Check Order Status:

  • Endpoint: checkOrderStatus(userID, apiToken, orderUUID)
  • Response: Current status of the order.

Database Schema

• OrderDB (SQL):

  • Fields: orderUUID, donorID, doneeID, amount, created_timestamp, update_timestamp, orderStatus (created, pending, complete/reject).

• OrderHistoryDB:

  • Fields: orderUUID, donorID, amount, timestamp, indexed by doneeID.

Additional Design Considerations

• Scaling the Service:

  • The order service can scale horizontally.
  • The list of donees is static and can be stored in a configuration service.

• Database Scaling:

  • MySQL can be sharded by orderUUID to handle increased load.
  • Read-heavy operations are anticipated, suggesting a focus on read optimization.

• Geographical Deployment:

  • Deployment strategy depends on requirements, with considerations for master/slave configurations for high availability and consistency.

Discussions During the Interview

• The interviewee demonstrated a good understanding of the requirements and system design.
• The complexity of the payment gateway was acknowledged as a factor in the overall system design.
• Discussions included idempotency handling, database choices (SQL vs. NoSQL), and the implications of distributed systems.
• Multi-region support and the challenges of synchronization across regions were highlighted.

Feedback and Follow-Up

• The interviewer noted the interviewee's ability to handle detailed technical questions and break down scenarios effectively.
• Suggestions for improvement included better time management during the interview and focusing on essential aspects of the design.
• Future considerations included handling refunds, social media integration, and the potential for recurring donations.

Conclusion

The mock interview provided valuable insights into the design of a donation system integrated with food ordering. The discussion covered a range of technical aspects, including system architecture, database design, and scalability considerations, while also highlighting areas for improvement in the interview process.