Requirements

Functional Requirements:

Obsługa i tworzenie menu - pod kątem restauracji.

Przeglądanie menu.

Tworzenie zamówienia.

Integracja z płatnością.

Podgląd zamówienia

Non-Functional Requirements:

Low latency (p99 < 500ms)

Real-time tracking (on map)

Scalability

High Availability

Capacity Estimation

10 000 000 Zamowień dziennie

Pik ruchu - 20x średnia

Maksymalna ilość zamówień na sekundę to 2300 zamówień na sekundę.

Ilość danych w zamówieniu - zawiera ID restauracji (8B), lokalizację zamówienia (adres - 200B), pewnie średnio ze 4 posiłki, każdy zawiera ilość i ID (16B * 4 = 64B). Pewnie jedno zamówienie może mięć 300B.

Każda transakcja generuje 10 dodatkowych requestów - autoryzacja, odświeżanie, statusy).Przepustowość zamówień na sekundę - 2300 * 300B = 0.7MB. Dziennie dochodzi ok 60GB zamówień. Miesięcznie dochodzi 2TB.

Procesowanie jednego zamówienia - średnio pewnie 2h.

Odświeżanie statusu - pewnie średnio 10%.

Liczba odpytań o status zamówienia - co 10 sekund lub na żądanie.

Liczba restauracji - 50000, każde ma 50 pozycji w menu - 2 500 000.

API Design

Restaurant Service:

• api/restaurant/v1/
  • GET /?(availalble=true)(onlyMyRestaurants=true/false&filtering) Lista restauracji
  • GET /{restaurantId}
  • POST /{restaurantId} - new restaurant, location, contact, deliveryareas etc
  • PATCH /{restaurantId} - deactivate
  • PUT /{restaurantId}/working-hours
  • GET /{restaurantId}/meals
  • POST/PUT/DELETE /{restaurantId}/meals/{mealId}
  • PATCH /{restaurantId}/meals/{mealId} - {"active":true, "from": date} deactivate

Orders Service:

• api/orders/v1
  • POST - składanie zamówienia, zwraca 201 jeśli się powiedzie z ID zlecenia; musi być idempotentny (idempotency-key); zwraca również w treści odpowiedzi przekierowanie do płatności
  • GET /{orderId} - pobiera status zamówienia
  • PATCH - zmienia status zamówienia (opłacony/wydany do dostarczenia/dowożony/odebrany)

Couriers Service:

• api/couriers/
  • PUT /{courierId}/localization

High-Level Design

Mamy dwa sposoby na komunikację się z systemem: przez aplikację mobilną (osobną dla restauracji, driverów oraz klientów) oraz przez aplikacje mobilne (również z podziałem).

Standardowo wszystkie requesty idą przez:

• CDN (dla aplikacji webowej), a jeśli nie ma danych źródeł, to do WebServerów, które serwują frontendy.
• Z aplikacji mobilnych/webowych żądania idą do LoadBalancera - tam jest terminowany SSL, oraz rozrzucany ruch na Api-Gateway
• Api-gateway dokonuje sprawdzenia zalogowania i uprawnień, rate-limitingu, deduplikacji żądań
• następnie każdy komponent ma swój reverse-proxy (Haproxy), na który jest kierowany dalej ruch.

Restauracja:

• restauracja może ustalać swoje menu, ustalać godziny pracy oraz akceptować zlecenia oraz wydawać je kurierom do doręczenia.
  • po ustaleniu menu, trafia one do cache'a, skąd klienci mogą je pobrać bardzo szybko
  • jeśli powstanie zamówienie do tej restauracji, powinna ona zaakceptować lub odrzucić zlecenie. Powiadomienie dociera do aplikacji Restauracji z użyciem modułu powiadomień lub WebSocket jeśli jest online.

Kurierzy:

• kurierzy cały czas mają śledzoną lokalizację
• po określeniu przez restaurację, że zamówienie można dostarczyć, system wybiera i proponuje kurierom dostarczenie zamówienia. Kurier może zaakceptować lub odrzucić zamówienie. W przypadku odrzucenia system wybiera kolejnego kuriera, którem proponuje dostarczenie.
• Po doręczeniu zamówienia, kurier sygnalizuje zrealizowanie dostarczenia

Klienci:

• Użytkownik określa swoją lokalizację/lokalizację dostawy
• Użytkownik pobiera listę dostępnych restauracji
• Użytkownik po wybraniu restauracji, może odczytać listę dostępnych posiłków
• Po wybraniu posiłków, użytkownik potwierdza zamówienie. Następnie jest przekierowywany do płatności.
• Następnie użytkownik przechodzi do statusu, który co jakiś czas jest odświeżany.
• Klient dostaje z użyciem notyfikacji informacje o zamówieniu.

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

Detailed Component Design

Dane restauracji powinny być cache'owane w największym stopniu. W przypadku ich braku - dane powinny być pobierane z bazy danych. Może to być baza danych dokumentowa - najbardziej odpowiednia do zapewnienia HA oraz do danych tekstowych.

Najważniejszym flow w systemie jest przetwarzanie zamówień.

Utworzenie zlecenia najpierw powinno być walidowane na podstawie aktualnych godzin pracy restauracji, danych dowozu.

Po pozytywnej walidacji, zamówienie jest zapisywane w bazie danych.

Następnie procesowana jest płatność - najpierw przekierowanie do jednego z dostawców płatności - żeby zapewnić HA w przypadku niedziałania jednego z nich.

Po otrzymaniu pozytywnej informacji o płatności, aktualizowany jest status zamówienia, jednocześnie w ramach Transaction Outbox Pattern jest zlecana wysyłka notyfikacji/websocket do aplikacji restauracji.

Restauracja potwierdza zamówienie lub odrzuca.

W przypadku odrzucenia zamówienia przez restaurację, zamówienie jest anulowane, notyfikacja jest wysyłana do klienta oraz zlecany jest zwrot płatności do klienta.

Jeśli zamówienie jest zaakceptowane, kolejne potwierdzenia są potrzebne: potwierdzenie gotowości oraz potwierdzenie wydania kurierowi.

Przy potwierdzeniu gotowości na kolejkę zamówień gotowych jest rejestrowane zdarzenie. To zdarzenie jest pobierane przez serwis przydzielający kurierów do zamówień. Jest to osobny serwis z własnym algorytmem.

Kurier jest informowany o zarejestrowanym zamówieniu. W momencie odbioru aktualizuje status na "przekazane kurierowi".

Skalowanie:

Baza danych zamówień najlepiej by była relacyjna i transakcyjna. Na podstawie danych lokalizacji można zastosować sharding - każde zlecenie ma prefix z id lokalizacji, który jednocześnie jest jego wirtualnym shardem. Określenie lokalizacji może być problematyczne w przypadku dużych miast lub całych aglomeracji.

Algorytm przypisywania zleceń kurierom powinien być wykonywany przez jedną instancję per shard. Aby zapewnić HA serwis może być replikowany, ale nieaktywny, jako że przetwarzanie powinno być wyłączne dla jednego consumera.

Shardowanie dotyczy zamówień, restauracji oraz kurierów.

Aktualizacja statusu zamówienia:

Każda aktualizacja wysyłą push/in-app notification, które aktywują aplikację, która pobiera najnowszy status zlecenia.

Statusy zleceń są cache'owane. Statusy są usuwane dopiero 1h po zakończeniu przetwarzania.