InstaCart Payment

October 24, 2021 7:00 PM PDT

---

This document summarizes the design interview focused on the InstaCart Payment System. The interview assessed the candidate's ability to design a payment processing system, covering both functional and non-functional requirements, as well as discussions surrounding technical choices and system architecture.

Avoiding double payments

Interview Details

• Level: L5 (Senior)
• Duration: 1 hour
• Topic Covered: Payment system

Requirements

Functional Requirements

• Roles:
  • Customer
  • Shopper
• Order Processing:
  • Customer initiates an order.
  • Payment service withholds/validates funds.
  • Funds are charged to the customer after 3-5 days.
  • Payments are made to the shopper for delivery and tips.
  • Refunds are processed back to the customer.
• Audibility: Ensure all transactions are auditable.

Non-Functional Requirements

• Accuracy: High accuracy in transactions.
• Consistency: Ensure data consistency and availability.
• Latency:
  • Low latency for synchronous operations (<500ms).
  • Moderate latency for asynchronous operations (<10 seconds).
• Fault Tolerance: System should handle failures gracefully.

System Design

System Design Diagram

• A diagram was created using a diagramming tool to visualize the architecture.

API Design

• APIs:
  • withholdFund(identity, amount, paymentDetail): Withholds funds from the customer.
  • makePayment(payer, payee, amount, paymentDetails, idempotencyKey): Processes the payment.

Steps for System Module Calls

1. Customer places an order through the web application.
2. Web application calls the payment service to withhold funds.
3. Payment service stores credit information in the payment profile database.
4. Payment service saves transaction details in the payment database.
5. Web application calls the order service to place the order.
6. Order processor scans completed orders and sends payment requests to the payment service.

Database Schema

• Payment Database:
  • Order database schema to manage transactions and payments.

Additional Design Considerations

• Scaling:
  • Transaction throughput estimation: 10 million monthly active users (MAU) with a conservative estimate of 300 transactions per second (TPS).
  • Data storage estimation: 30TB over 5 years.
  • Consider sharding by payment ID or order ID for scalability.
• Payment Processor Flow:
  • Locking mechanisms for records during transactions.
  • Handling of idempotency to ensure transactions are processed correctly.

Discussions During the Interview

Functional Requirement Discussion

• Clarified the need for grocery/merchant information in the API.
• Discussed the idempotency of the withholdFund() call.

SQL vs NoSQL

• Discussed the trade-offs between SQL (MySQL) and NoSQL databases.
• Considered consistency and fault tolerance in database selection.

Fault Tolerance and Scaling

• Addressed how to manage order processor failures and the importance of idempotency.
• Discussed the need for a backup service and timestamping for recovery.

Audience Feedback

• Emphasized the importance of estimating storage and bandwidth requirements.
• Suggested focusing on high-level design while being prepared to dive deeper into specific areas as needed.
• Discussed the necessity of understanding both synchronous and asynchronous transaction handling.

Conclusion

The interview highlighted the candidate's understanding of payment system design, including functional and non-functional requirements, database choices, and scaling considerations. The discussions provided insights into the complexities of building a robust payment processing system.