Design GoPuff

November 4, 2024 6:15 PM PST

---

This document outlines the system design for GoPuff, focusing on the functional requirements, operational flow, and various components involved in the local delivery system. The design aims to support a high volume of daily active users and fulfill orders efficiently from nearby fulfillment centers.

Functional Requirements

• Local delivery from fulfillment centers within one hour.
• Emphasis on ordering functionality over search.
• System must scale to support:
  • 100 million daily active users (DAU)
  • 10,000 fulfillment centers
  • 20 million items sold daily
  • 1,000 cities
  • 10,000 SKUs
  • 1,000 queries per second (QPS)

Operational Flow

1. Order Fulfillment Process:

   • Identify which warehouse can fulfill the order.
   • If the warehouse lacks inventory, find availability within a specified range.
   • Maintain inventory data including SKU, warehouse ID, total quantity, and reserved quantity.

2. Inventory Availability:

   • Use a recommendation system to precompute preferences.
   • Filter available items based on inventory data.

Ordering System

• The system must handle 1,000 QPS with considerations for concurrency control:
  • Implement pessimistic locking for database rows.
  • Use optimistic concurrency control to manage conflicts on single SKUs, which is more efficient and supported by PostGreSQL.

Inventory Management

• Total data size estimation: 10,000 SKUs x 1,000 cities x 50 = 5GB.
• Use optimistic control to reserve items effectively.

Warehouse Service

• Manage pick and pack operations.
• Payment processing:
  • Payment must be processed before sending the order to the warehouse.
  • If payment fails, the system needs to invalidate the reservation.

Order Processing Steps

1. User adds items to the cart.
2. Checkout process initiated:
   • Add payment instrument.
   • Process payment:
     • Place payment in a queue.
     • Update inventory to make the reservation permanent upon successful payment.
     • If payment fails, remove the reservation.
3. Inventory status transitions:
   • Available -> Temp hold -> Ready to ship -> Shipped -> Received.

Order Table Structure

• Fields: userID, orderID, skuList (with SKU and quantity), status (pending, temp reserved, ordered, picked/packed/delivered).

Payment Processing

• Payment is asynchronous; inventory updates must reflect payment status.
• Upon clicking “pay,” the system prompts the user for payment information, which is processed through a third-party service.
• Use an idempotent key to manage payment processing and retries.

Additional Considerations

• Discussed the importance of user experience and the need for a clear workflow in service division.
• Emphasized the significance of distributed systems, scalability, and fault tolerance in handling spikes in demand.