Foodpanda Clone API Design: Multi-Vendor Backend

A multi-vendor food delivery backend has three actors hitting the same order object simultaneously. Here's how to design the API layer of a Foodpanda clone so that doesn't fall apart under load.
1. Core Entity Separation

• User - customers, decoupled from auth provider.

• Vendor — restaurant profile, menu, operating hours, commission rate.

• DeliveryPartner — availability status, live location, assigned orders.

• Order — the shared object every actor mutates at different stages.
  2. Endpoint Grouping by Actor, Not by Resource
  Instead of one generic /orders namespace, split by role-specific gateways:

• /customer/orders — create, track, cancel.

• /vendor/orders — accept, prepare, mark ready.

• /partner/orders — pick up, update location, mark delivered.
  This keeps permission logic simple and avoids one bloated controller trying to serve three different clients.
  3. Order State Machine
  Model order status as an explicit state machine, not a free-text field:

• placed → accepted → preparing → ready_for_pickup → picked_up → delivered → completed

• Reject any status transition that skips a step at the API layer, not just in the UI.

• Log every transition with a timestamp — this becomes your dispute-resolution audit trail.
  4. Real-Time Layer

• WebSockets for: live order status, delivery partner location pings.

• REST for: menu browsing, order history, payment confirmation.

• Message queue (e.g. Redis Streams or Kafka): decouple order-placed events from restaurant notification and partner-matching logic.
  5. Vendor Isolation
  Every vendor's menu, pricing, and commission logic should be queryable independently, with no cross-vendor joins in hot-path endpoints.

• Index orders by vendor_id and partner_id separately for fast dashboard queries.

• Cache active menus per vendor with short TTLs — menus change less often than orders.
  6. Partner-Matching Endpoint
  Keep partner assignment as its own service, not embedded inside order creation:

• Input: order location, ready time estimate, nearby partner availability.

• Output: ranked list of eligible partners, not a single hard assignment.

• This makes it easy to swap in a smarter matching algorithm later without touching order logic.
  7. Rate Limiting by Actor Type
  Customers polling for order status need generous limits; vendors bulk-updating a menu need burst allowance; partners sending location pings every few seconds need their own lightweight, high-frequency endpoint separate from the main API gateway.
  8. Idempotency on Write Endpoints
  Order creation and payment confirmation must accept an idempotency key. Network retries on flaky mobile connections are the norm, not the exception, in delivery apps.
  9. Versioning Strategy
  With three different client apps hitting the same backend, breaking changes ripple fast:

• Version endpoints explicitly (/v1/customer/orders), never rely on implicit compatibility.

• Keep a deprecation window of at least one full app-release cycle before removing an old version.

• Maintain a changelog per actor namespace — customer, vendor, and partner apps often update on different release schedules.
  9b. Sample Order State Payload
  A minimal but useful order-state event looks like this in practice:

• order_id, vendor_id, partner_id, status, status_changed_at, previous_status

• Emit this as an event on every transition, not just a database row update — it's what powers real-time notifications to all three apps without polling.

• Keep the event payload actor-agnostic; let each client app decide what to render from it.
  10. Observability From Day One

• Structured logging per order ID makes tracing a single order across services trivial.

• Track p95 latency separately for each actor's endpoints — a slow vendor dashboard shouldn't be masked by fast customer-side metrics.

• Set alerts on state-machine violations; a spike in rejected transitions usually signals a client-side bug before it becomes a support ticket.
  Conclusion
  A clean API layer is what separates a Foodpanda clone that survives lunch-hour traffic from one that quietly drops orders under load. Get the actor-based endpoints, the state machine, and the real-time layer right early, and the rest of your Foodpanda clone build becomes far easier to scale and maintain.