Food Delivery Platform Case Study

This is a food delivery platform for users in North America. It’s worth mentioning that we worked on this project before 2020, so some features and architectural designs that may seem common today were quite advanced and even ahead of their time back then.

At the beginning, the project only implemented ordering functions through H5 pages in WeChat, and evolved into a mature food delivery platform system, with Android, iOS, and mini-programs all developed natively. This project allowed me to fully utilize all my knowledge, experience, skills, and thinking, making it one of the most memorable and satisfying projects for me.

As is well-known, a food delivery platform should include client-side (for consumers), merchant-side, rider-side, and in some large platforms, a supply chain-side. Let’s start by discussing the various roles on the platform:

Backend Roles:

  • Operations: Needs to view daily orders by region, monitor rider assignments, merchant updates, promotions, and manage these aspects.
  • Customer Service: Requires access to all order details to handle complaints, oversee reviews, and decide whether to respond, delete reviews, or contact customers.
  • Riders and Dispatchers: They work together, with dispatchers assigning paid orders to nearby riders. Riders are responsible for accepting, delivering, and completing orders within the specified time.
  • Merchants: Classified under backend roles due to passive operations like creating accounts and coordinating rates with the platform, with direct operations handled through the merchant-specific application developed later.

Frontend Roles:

  • Merchants, Users, and Riders: These are the roles interacting directly with the front end.

To clarify, backend roles are management-focused, overseeing and managing the platform’s operations. Frontend roles involve guiding users through designed business processes, such as helping consumers place orders, merchants accept them, and riders deliver them.

Technical Aspects: The core process of the platform is the order-to-delivery workflow. While it may seem simple, this business process diagram is much longer than the longest product detail page on Taobao.

We needed to support 50,000 to 100,000 orders per day. The backend used ROR (Ruby on Rails) + MySQL single instance. From the start, we adopted a front-end and back-end separation model. The server computation data is limited to order submission, payment, merchant preparation, rider delivery, and completion, with most pressure on the front end.

Early Stage:

  • ROR provided all APIs.
  • React was used to build H5 pages.
  • Redis was used minimally.
  • Payment features and maps only required location services.
  • Platform backend used Angular.js.
  • The merchant and rider sides were later developed using React.

Mid Stage:

  • Major change was the need for a mobile app.
  • Focus was on ROI, aiming for minimal cost to launch the app. We chose hybrid development using React Native due to its ease of learning and low cost.
  • The mobile app expanded to include merchant-side Android and iOS, rider-side Android and iOS, and user-side Android, iOS, and WeChat Mini Program.

Large Iteration:

  • Developed a dispatch platform using Google Maps with React.
  • Manual dispatching was chosen over automatic due to lower user volume and order volume at that time, and the high cost of developing algorithms.

Later Stage:

  • Converted user-side Android and iOS apps to native development.
  • Continuous code optimization and feature iterations.
  • Optimization included front-end (user experience) and back-end (performance), along with interface, subsystem, and service splitting.
  • Also involved static page processing, embedding H5 activity pages in native systems, SQLite for local storage and caching, etc.

New and small technologies were applied in this project, which is one reason I enjoyed it—it allowed me to fully utilize my creativity and knowledge.

Backend Optimization:

  • Optimized the dispatch platform with algorithms and front-end page enhancements.
  • Achieved a “semi-automatic” dispatch platform, improving efficiency and reducing average delivery time per order by 15.2%.

Queues:

  • Used for SMS notifications, login expiration handling, scheduled tasks, temporary data statistics, search, recommendations, tracking, and data collection.
  • The application grew from several megabytes to over 100 megabytes as features increased.

Cost Control:

  • Used only 8 servers in the later stages, with annual costs around $80,000, including third-party interface service fees. Given the platform’s user scale, this operational cost was very controlled.
  • The development team was kept to about 60 people, reflecting high efficiency.