Loading...
List the key functional requirements for the system (Ask the AI for hints if stuck)...
Итак, делаем систему для паркинга для стран по всему миру. Пользователь должен мочь бронировать места на опредененных парковках на определенное время. Он должен указать тип машины (легковушка, внедорожник, мотоцикл и тд), оплатить -> получить QR. На парковке показать qr в сканер, получить проезд на парковку. При выезде - предоставить qr по которому заезжал, оплатить если что просрочку у уехать.
List the key non-functional requirements (performance, scalability, reliability, etc.)...
Система должна выдерживать нагрузку в часы пик, не отказывать, мочь обрабатывать выезд пользователя и въезд по qr коду ВСЕГДА (это более важно, чем забронить при отказе остальной системы). Система не должна позволять 2 брони на одно и то же время на одно место. При отсутствии машины долгое время на свое место - освободить его…
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
Предположим что одна парковка в среднем на 100 машин. В городе, например, 50 парковок, подключенных городов в стране 10, подключенных стран 5. Получаем 100*50*10*5=250 000 мест. А всего парковок 2500 (полезно для шардинга). Также надо учитывать слоты. Допустим 24 слота на день, бронь на месяц -> 24*30=720 слотов для каждого места. 250000*720=180 000 000—> 180 миллионов. В целом около рабочая нагрузка для одного инстанса постгри. В памяти - 180000000*128/1000/1000=23 040гб хранения. При очистке старых слотов монотонно расти не будет. Возьмем 30гб для уверенности. Также нужно учитывать саму нагрузку на сервис и различные операции. Это запись и чтение.. чтения будет точно больше - ведь мы получаем список занятых и не занятых слотов по всей парковке. А запись одна. Предположим что у нас около 100rps на запись, 10_000 на чтение. Также учитываем, что большая часть броней на малый период (1-4часа), но есть процентов 20 на день и 10 на то, что больше дня. Это также оптимизирует место
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
есть объект слот, день, месяц, запись (занятые слоты). В api - ручки на просмотр записей, бронирования слотов.
Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.
Есть три основных севриса:
при оплате slots-service ходит через api-gateway в payments-service для создания платежей. ждем ответа об успешной оплате. все это время слот в состоянии временной блокировки -- отображается как занятый, но треубует подтвержения оплаты. потом также будет требовать подтверждения использования.
10_000 rps на чтение ---> нужен кэш по занятым слотам. инвалидацией занимается ttl кэша и сам сервис slots-service
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...
users: id (pk), name, surname, email, password (hashed)
vehicles: id (pk), user_id (index to users id), type, plate_number (index)
parking: id(pk), country, city, address, coordinates (index) (для отображения на картах)
parking_lot: id(pk), parking_id(index), orientation [тут бля сложно, т.к. у разных парковок разные форматы], status (бронь/не бронь СЕЙЧАС)
booked_slots: id(pk), parking_lot(index) start_time, end_time, user_id(index), vehicle_id, is_payed, is_occupied. умный индекс на start_time+end_time для поиска по времени.
payments: id(pk), user_id(index), created_at, payment [без понятия как оно выглядит, но пускай тут будет]
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
рассмотрим самые главные мехники