Проектирование архитектуры сервиса доставки еды
HTML-код
- Опубликовано: 2 авг 2024
- Entry-level видео на тему проектирования воображаемого сервиса доставки еды.
Идея проекта от t.me/anelfer:
Сервис доставки еды, человек делает заказ, и может отслеживать его статус. После создания заказа, кухня получает уведомление о новом заказе, (какой-то красивый интерфейс, сайт), принимает его (подтверждает, что увидела заказ), когда начинает готовить, курьерам идет рассылка о заказе, 1 курьер может взять заказ. После приготовления, курьеру доступна кнопка забрать заказ, он забирает его и едет к заказчику. (все статусы у заказчика отображаются), после чего курьер нажимает доставлено и автоматически завершается заказ.
Мой Java роадмап - zhukovsd.github.io/java-backe...
Мой телеграм канал - t.me/zhukovsd_it_mentor
Схемы и заметки со стрима в комментариях к этому посту - t.me/zhukovsd_it_mentor/36
Поддержать - boosty.to/zhukovsd
00:00 Таймер
09:44 Начало
11:20 Высокоуровневная схема архитектуры
21:35 Состояния заказа
34:45 Схема базы данных
44:20 REST API, авторизация
50:05 REST API customer сервисов
59:35 REST API restaurant сервисов
1:09:45 REST API courier сервисов
1:19:45 Как могла бы выглядеть работа над проектом
1:31:20 Ответы на вопросы
Диаграммы из видео - t.me/zhukovsd_it_chat/8867
По больше таких стримов, Kotlin, Python, Rust - все и так изучают, а вот правильное проектирование и системный дизайн это то, чего так не хватает. Спасибо )
Этому учат в ВУЗах, а еще книжки попробуй тематические почитать
вообще поподробней хотелось по этой теме. Особенно об инструментах
@@vincentvince2136 В книгах тоже много теории, нужен сам процесс.
где вы тут увидели про проектирование и дизайн? )))
сначала до уровня хотя бы мидла дорасти, а потом грязными ручонками лезь в архитектуру.
Первый раз смотрю подобное видео - случайно попало в рекомендованные. Очень интересно было посмотреть и понять ход мыслей разработчика при работе над проектом.
Я как маркетолог часто слышал обрывки диалогов программистов и теперь более понятно о чем идут столь оживленные дискуссии )
Ну и, по правде говоря, при работе над улучшением продукта, мне реально интересно знать как этот продукт устроен технически. Теперь ясно как в целом работает приложение.
Было бы интересно в таком же формате разбор от ПМа, продакта и бизнес аналитика.
P.S. Кому нудно - включайте на х1,75. Отлично смотрится.
нашел это видео после после просмотра видео о каналах шизофреников
😅😅😅
Жесть, ну там конечно и клоуны 🤡
Да у меня тоже они всплывают. Хотя никогда не кликал
Точно также тут оказался
Что за каналы такие? Очень интересно.
Более содержательного видео не могу вспомнить, пусть поверхностно, но за полтора часа дать такое комплексное описание целого, почти реального проекта, это просто вау, что самое главное понятное. Премного благодарен автору, подписка однозначно.
На редкость полезное видео. Дизайню интерфейсы, чисто из любопытства решил поинтересоваться за архитектуру - теперь всё прям по полочкам расставилось. Спасибо.
Огромное тебе спасибо, Гэри Олдман, за прекрасное изложение материала ещё и на русском. Посмотрел за раз, не отрываясь. Успеха тебе в ютуб-пространстве.
Почитал комментарии и аж обидно стало. Видео просто пушка. Автор сразу же обозначил цель видео, наложенные ограничения и в чём вообще задумка и мне кажется, автор цели достиг, с задачами справился и ограничения учёл.
Видео, на мой взгляд, получилось очень информативным, полезным и интересным. Процесс проектирования сложных сервисов действительно показан хорошо. Даже если бы обсуждался реальный сервис - уже было бы от чего оттолкнуться и что начать обсуждать командой из нескольких человек, а не в одно лицо. Такой результат за полтора часа - это очень круто(понятно, что автор потратил больше, чем полтора часа, рисование схем, продумывание сценариев - это довольно много времени, но всё же). Да, много моментов, которые просят пояснения, много где можно подискутировать и поспорить, но видос не про это вовсе.
Сергей, большое вам спасибо! С дикцией у вас тоже всё отлично, да и в конце концов, вы не теледиктор, вас не за красоту слога приходят смотреть.
Спасибо 👍
@@zhukovsd_it_mentorвидео класс, продолжайте в том же духе
Было очень интересно послушать по архетектуру и технологии. Спасибо за интересный материал! Успехов вам!
Это что-то конечно..случайно наткнулся на это видео и буквально залип. Огромное спасибо автору за очень ценный урок и прекрасное, доходчивое объяснение!
Огромное спасибо. Очень интересно, а главное, доходчиво получилось. Для меня как будто открылся закулисный мир разработки.
Офигенный материл! Побольше бы таких с аргументированными объяснениями подходов.
Еще не смотрел полностью но кликнув на середину уже офигел от качества!!! Гляну попозже, поддержу сейчас!
Спасибо, посмеялся.
Классическая ошибка "микросервисы ради микросервисов", аналогично redis и rabbitMQ. Аналогично столь подробное планирование архитектуры простого проекта.
При этом нет обоснования выбора того или иного пути.
Согласен. Вместо одного большого монолита мы сделаем кучу сервисов, которые юзают одну и туже бд. По сути получился распределённый монолит, с кучей побочных проблем: deploy, масштабирование, сомвестимость api
Вы всё верно пишете, но задачи спроектировать коммерческий проект я для себя не ставил при подготовке к этому видео. Цель видео - озвучить ход мыслей, и схематично показать процессы проектирования. Основная моя ЦА - джуниоры и те кто готовится к своей первой работе, я стараюсь чтобы понятность моего контента соответствовала целевой аудитории.
Вопросы монолита и микросервисов, очередей и прочее - вопросы более высокого уровня, для понимания и обсуждения которых нужен определённый уровень и опыт.
Но так как на канал приходят люди с таким опытом, как вы, например, постараюсь в будущем делать более явный дисклеймер на эту тему.
Спасибо за фидбек.
@@radik353 очень странный подход - показывать именно формально бюрократическую часть работы, гиперболизируя её и не объясняя логики. Ну да бог вам судья
@@zhukovsd_it_mentor Я пропустил в этом видео момент где вы хоть что-то проектируете. Укажите таймкод, пожалуйста.
@@mightybobka 1:39:41
Круто, очень полезная информация!
Гениальный видос, ничего подобного не видел за время активного поиска обучающего материала!
Проходили про базы данных в вузе, про бек и фронт - на тестовых заданиях в ШМЯ. А вот про API не знала, это было новым. Спасибо! Это круче, чем онлайн курс.
Спасибо за проделанную работу!
Спасибо тебе, Гэри Олдман, за видео!
Спасибо большое за такую полезную информацию!
просто находка! вы очень крутой
Содержательно, без воды. Есть понимание что и как надо осваивать, после того как разобрался с "Hello world" :D
Спасибо, очень хороший разбор
Спасибо! Побольше бы такого годного контента на ютубе
Спасибо, крутое видео, не каждый выкладывает структуру реального проекта и процесс проектирования. Вроде простое приложение, но офигеть насколько сложной схема получается, и это без всяких нюансов и общепринятых каких-то дополнений.
Спасибо за отзыв.
Всё-таки это не архитектура реального проекта, а скорее упрощенная демонстрация хода мыслей, с которыми подходят к проектированию.
Очень многое не рассмотрено, но и так полтора часа получилось.
Спасибо за качественную информацию!
Очень интересно. Спасибо!
Пока что отсмотрел не всё, но очень интересное видео. Показывает как можно и на что разбить проект, чтобы дальнейшая разработка шла по сформированной программе. И самое главное, что это прямая трансляция, где всё происходит без вырезания некоторых сцен(хотя понятно, что вопрос рассматривался ранее и рассматривались разные варианты).
Хорошее видео. Больше таких. )
Очень крутое видео! Увидеть бы реализацию)
Спасибо! Хотелось бы подробнее про аутентификацию, авторизацию, логирование, метрики, балансировку нагрузки и т.п.
Видео супер, в качестве обучаеющего материала для разного уровня специалистов, спасибо автору за проделанную работу!!
Здравствуйте, спасибо большое, это очень круто!
Хочется больше таких видео! Вы супер, у Вас всё обязательно получится!!
просто кайф, спасибо!
Спасибо, очень интересно
Спасибо, очень любопытно посмотреть как этим занимаются на практике. Я и сам учусь на программиста самостоятельно и понимаю, что самое главное в этом деле - архитектура. Это - начало начал и именно этим мне и нравится заниматься, нежели кодингом. Изучил немного тему EDA, событийно-ориентированной архитектуры и DDD, предметно-ориентированный дизайн приложений. Считаю, что это лучшая связка для архитектуры практически любых приложений, так как события убирают связность между модулями, а предметные области позволяют правильно разбить приложение на отдельные службы.
У вас разбивка похожа на DDD, но отличие в том, что у вас все данные хранятся в одном месте, что противоречит DDD. По DDD каждая служба (сервис) должна хранить свои данные в своей независимой базе (теоретически СУБД можно использовать одну, но базы должны быть разные). По DDD каждая предметная область содержит как данные, так и логику для их обработки (по сути как и объект в ООП), что создаёт изоляцию и независимость от других предметных областей. А это даёт больше свободы и простоты в поддержке. Можно любую предметную область удалить, добавить, и это будет абсолютно не заметно для других, если используются события для общения, а не прямые RPC и прочие такие запросы с ожиданием ответа. При чисто событийной архитектуре всё общение идёт через шину событий, и она является единственным модулем, с которым напрямую связаны все предметные области. А это - максимальная изоляция друг от друга - то, к чему стремятся многие программисты, понимая весь ужас и тяжесть монолитных и спагеттеобразных приложений, где все связи между модулями и данными прямые.
Не лучше ли всё-таки использовать DDD?
Согласен с вашими рассуждениями о ценности DDD.
В этом видео моей целью было по продемонстрировать ход мыслей при проектировании и наглядно по верхам показать схемы, БД, API.
Но проект я выбрал довольно сложный, плюс, полтора часа - и так уже много, поэтому местами вышло поверхностно.
В последующих видео по проектированию стараюсь не повторять эти ошибки.
Это действительно важное принципиальное замечание, т.к. если уж упомянули о микросервисной архитектуре, то надо придерживаться и требований к микросервисам (у каждого свои данные). Иначе для тех, кто только начинает постигать системный анализ это может надолго создать неправильный подход.
Супер, очень крутой стрим)
Спасибо , бро. Очень Полезная информация.
Супер классное видео!
Просто отлично!
Рад за автора, что он прочитал книгу "Микросервисы на практике"
Круто 👍🏻
Ашалеть, теперь и Гари Олдман в разрабах)
позновательный контент благодарю
Шел 2023й, мы выкладывали видео по программированию в 720p... Впрочем, спасибо за материал.
Спасибо, очень крутой high-level обзор! Как раз то, что искал для постепенного перетекания в fullstack
А с каких пор фул стек пишет высоконагруженные системы?
Интересное видео, узнал для себя пару новых вещей
отдельно понравилось рассуждение
"ну сейчас все делают микросервисы поэтому мы тоже сделаем их"
чевооооооо
с ровного места огромные оверхеды разработки добавлены
Спасибо большое
Спасибо мужик.
Супер!
Соо миллионов лайков Тебе, дорогой!
мы с пацанами расходимся после катки
так же тот самый чел который решил рассказать коротенькую схемку с большой прибылью:
В таблицу Orders я бы добавил не одно поле timestamp, а что-то типа created и delivered - дата создания заказа и его доставки. Также можно было бы добавить таблицу а-ля "Order_Rating" со связью по полю id таблицы Orders, где была бы оценка заказа и комментарии по нему.
Ни разу не делал схемы и не знал как они делаются. 3 года уже пишу свои проекты просто на абум, замотивировали почитать книжки по проектированию
наобум
интересная информашка. буду в бедующем наверное рассуждать по твоему же принципу.
Мощный видос!
Классный ход мысли. Видно, что много раз делали подобный дизайн. Интересно, можно ли получить подобный ход мысли на синтетических задачах проектирования?
Как и со многим другим, это вопрос опыта. Помогают книги по проектированию, эксперименты с пет проектами, участие в проектировании рабочих проектов.
@@zhukovsd_it_mentor какие книги посоветуете? И есть ли реальный от них прок в понимании архитектуры?
@Jilexa
Самое главное - в рабочих проектах учиться у старших коллег и постепенно участвовать в проектировании.
По книгам:
- Проектирование бизнес логики - Domain Driven Design by Eric Evans
- Software Architecture Patterns
- Если в проекте есть БД, SQL/NoSQL, хорошо почитать что-то про проектирование хранилища, например книгу "SQL Antipatterns"
Бальзам для ушей
Научился по этому видео зарабатывать воображаемую зарплату!)
Рад помочь 👨💼
Блин классно. Единственное для новичков хотелось бы видеть полноценную ER диаграмму
видео с мелким текстом в 720p
Гениально
Спасибо.
На троечку конечно аналитика и проектирование
Ну хоть на троечку 🙂
Очень полезно и интересно, будет ли продолжение
Практическая реализация этого проекта не планируется, идея видео - описать ход мыслей при проектировании.
Но мне интересно было бы продолжить эту серию видео, спроектировав что-нибудь ещё, поэтому буду рад услышать предложения.
Я сейчас прохожу обучение по джама, скоро присаединусь
@@zhukovsd_it_mentor p2p обменник,
@@user-rv9ss5ce7z да, p2p актуально
я - весьма токсичный и нередко гажу в комментах (борюсь с этим, но не всегда получается). А это видео - тот случай, когда хочется поблагодарить автора за проделанную работу!
Человек, который честен себе
Приложение вкусвилл идеальное во всей планете берите пример
круто
25:11
Интересный подход, вроде все просто но раньше не приходило такое в голову, спасибо.
Получается помесь BPMN и проектирования, на чистом BPMN конечно сам процесс был бы более качественно описан, но зато в таком виде удобно изучать архитектуру.
В работе постоянно есть выбор между "обобщить" и потерять часть информации или "детализировать" но в итоге перегрузить схему так что она становится не читаемой. Вам удалось соблюсти хороший баланс. Это тоже важный навык который требуется нарабатывать.
Спасибо, в этом и была идея, не перегружать слушателей терминологией, но при этом озвучивать ход мыслей по проектированию.
@@zhukovsd_it_mentor тебе спасибо за видео, для меня это новый мир особенно те видео где ты разбираешь проекты, то как искуссно ты говоришь о недостатках при этом не обижая людей но в то же время конструктивно это что то недостижимое.
Я сам по работе лид и делаю ревью кода Джунов и мидлов и приходится так же общаться с людьми, естественно я стараюсь быть минимально токсичным, но по сравнению с тем как ты это делаешь Я просто ребенок)). Очень много полезных приемов общения у тебя увидел.
Писать код на самом деле самое простое что есть в работе Лида. Самое сложное это давать обратную связь и уметь явно излагать свои мысли.
Если это читают начинающие ребята то мой совет учитесь у этого человека излагать мысли это гораздо важнее умения писать код)))
@You2Ber42 спасибо, очень приятно что кто-то понял ровно то, что я пытаюсь донести в ревью между строк
Спасибо. Очень полезная информация. На кого же похож автор. Мне кажется на Жан Батист Эммануэль Зорг - вымышленный персонаж, главный злодей научно-фантастического фильма Люка Бессона "Пятый элемент". Сыгран знаменитым британским актером Гари Олдманом. )
Да,гари вообще играет нормально во всех фильмах,понравилась его роль в фильме - книга иллая.
Смесь Тодда Говарда и Мэрлина Мэнсона
Надо учесть ещё возможность получения отчетов как из платежного сервиса, так и гибридных когда в одном отчете информация из всех серверов и сервисов.
И логирование всего и вся
Мне кажется проектирование нужно начинать с логической модели приложения. Все остальное должно после нее проектироваться. Ну как минимум так проще.
я 9 минут и 45 секунд ждал начала
Бро, спасибо за контент, я джун и мне очень интересно. Вопрос - что если завести price_history где хранить все исп. скидки / наценки по позиции, а в ордере хранить уже итоговую стоимость ? Видел на проекте discount и price, которые вообще непонятно как формировались (можно было разобрать только по логам). И еще один - хранить деньги в копейках, а кол-во в x1000 это тру подход ?)
Мне кажется, те требования, которые не будут реализованы сейчас , они все равно должны быть отмечены как подпроцессы.
Для тестировщиков тоже полезно будет
Я сразу скажу, что новичок. Но меня запутала тема про появление delivery совсем. На плане проектирования сущностей Delivery не было, разве по REST API не надо было проектировать что-то вроде обновления статуса заказа, то есть PATCH /order/${id} с передачей статуса как вы делали в одном из методов Restaurant API ?
За видео спасибо, годное. Успехов
Спасибо за отклик.
Полную диаграмму сущностей я не показывал, сконцентрировался на статусах заказа и том, как заказ меняется внутри системы в процессе оформления, приготовления, доставки.
Идея REST API доставки в том, что мы работаем с сущностями из предметной области доставки. Например, метод приёма доставки в работу курьером - `POST /delivery/${id}`. Сервис, обрабатывающие этот запрос, работает с сущностями "delivery", который связаны с сущностями "order" (заказы). Приём delivery курьером в рамках описанной архитектуры приводил бы к тому, что delivery-rest-api сервис изменит статус заказа на `DELIVERY_PICKING`.
И хочу заметить, что в реальности многие аспекты придуманного дизайна очень сильно бы изменились. Видео не про готовый дизайн, а про процесс проектирования и ход мыслей.
топ контент
Случайно попал на видео, у заказа нужны свойства(уже стандарт) свойства заказа могут быть разного типа… пользователей делят не по таблицам а по группам!
Сергей, спасибо за видео! Вы применяете необычные верхнеуровневые нотации. Могли бы подсказать, подобный формат описания API - по какой-то спецификации или свои наработки?
Добрый вечер. Подобной формой записи пользуюсь для себя на ранних стадиях продумывания схемы эндпоинтов.
Когда приходит время формализовать схему, пользуюсь форматом спецификации OpenAPI.
Полезное видео, посоветуйте литературу по этой же тематике
Трудно посоветовать что-то конкретное, потому что видео затрагивает по верхам несколько разных тем, но постараюсь:
- Проектирование бизнес логики - Domain Driven Design by Eric Evans
- Паттерны проектирования архитектуры (бесплатная книга) - get.oreilly.com/rs/107-FMS-070/images/Software-Architecture-Patterns.pdf
- Проектирование БД - SQL Antipatterns by Bill Karwin
- Проектирование API - REST API Design Rulebook by Mark Masse
@@zhukovsd_it_mentor Спасибо!
В основном делаю( pet project)фронт на жабе используя API сервера,в бэк боюсь лесть 😂😂думаю там намного логика сложнее.
Курьеры работают за "profit" :D
Не очень нравится табличка orders, думаю, следует в табличку orders добавить общую цену заказа, так как общая стоимость может не равняться стоимости всех товаров в корзине, могут быть модификаторы на общую цену в зависимости от количества или действующих акций. Да и сами цены, по уму, на каждую позицию по предметной области должны храниться в отдельной таблице, так как стоимость в каждый временной промежуток является частью публичной оферты.
Скажи пожалуйста, что лучше выбрать для начала карьеры в данный момент C# (.NET) или Java (Spring) ?
Привет. Начать карьеру можно и на C# и на Java, принципиальной разницы нет.
Результат будет определён другими факторами, а не выбором языка. Писал про это статью - t.me/zhukovsd_it_mentor/86.
Очень хочется увидеть реализацию этой схемы! Чтобы был понятен полный цикл разработки
Получился бы слишком объёмный проект.
Я спроектировал проект попроще, а студенты реализовали:
- Проектирование - ruclips.net/video/vI9KEs9FsHY/видео.html
- Разработка - ruclips.net/video/LLaJgrP6S1A/видео.html
В какой backend service поместить таблицы order и order_items? Целесообразно ли создать лучше новый сервис orders и помещать все сущности касательно заказов
Не надо бить на микросервисы если у вас нет команды чтобы поддерживать интерфейсы консистентными, писать end-to-end тесты и прочее дерьмо. К тому же в 95% случаев ваш стартап загнется раньше чем ему понадобятся микросервисы.
Мне кажется, что прямоугольник рест апи должен быть не параллельным, а последовательно включен в три параллельные сущности потому что он функция этих трех аргументов . Или нет !?
Сам я новенький в разработке, поэтому интересно, сколько по вашему мнению требуется людей на такой проект? Понятно, что зависит от сроков, но вот если не торопиться никуда и соблюсти соотношение цена/время сколько человек обычно делают такой проект и за какое время?
Если ткнуть пальцем в небо, и допустить, что ограничимся только тем функционалом что был на схемах, то думаю что 2 опытных мобильных разработчика и 2 бэкендера за 2-3 месяца сделали бы рабочий прототип.
@@zhukovsd_it_mentor не считая архитектора, пары дизайнеров, бизнес /системных аналитиков, PO, PM, пары девопсов, пара QA, бухгалтера )). Да и мобильные команды стоит увеличить сразу до 2-х разработчиков…
@@gribovmax А маркетить и продавать кто будеть???
Зачем всем сервисам иметь доступ ко всем базам? Зачем тогда вообще разделять бд?SQL не справится с сохранением токенов? Есть неугасимое желание поддерживать больше инфраструктуры?
Еще я бы использовал ролевую модель и после определения роли отправлял бы юзера куда надо.
А в остальном прекрасный вводный гайд, спасибо. Было интересно
Нужно больше практической информации о документации при проектировании продукта
Спасибо за информативное видео. Хотел уточнить как будет вызываться REST Api после попадания сообщения в очередь RabbitMQ. Как я думаю, если это клауд то в RabbitMQ мы пишем например Azure function (AWS lambda) которая будет триггериться входящим сообщением и дальше будет вызываться соответствующий REST Api? А если это не в клауде то придется писать свой листенер для очереди?
Вариантов много, и они зависят от нефункциональных требований к продукту, особенно от требований к стеку и выбору облачного вендора, требованиям к бюджету на эксплуатацию продукта.
Почему отношение Order_Items к Menu_items - 1:1, а не n:1 ? Одна позиция меню может участвовать во многих заказах. 43:07
Идея в том, что цена и количество конкретного товара может отличаться от заказа к заказу, поэтому 1:1
Какие книги вы можете посоветовать по этой теме? Желательно с самых азов.
Книги дают пользу только в контексте вашего текущего опыта. Советую вам расти в профессиональном уровне, как разработчику, постепенно участвовать в процессах проектирования, и читать те книги, которые актуальным вашим текущим задачам.
По книгам, могу посоветовать такой набор:
- Проектирование бизнес логики - Domain Driven Design by Eric Evans
- Архитектура: Software Architecture Patterns, Fundamentals of Software Architecture: An Engineering Approach, Designing Data-Intensive Applications
- Если в проекте есть БД, SQL/NoSQL, хорошо почитать что-то про проектирование хранилища, например книгу "SQL Antipatterns"
@@zhukovsd_it_mentor Благодарю!
эмэмил сендер сервис!
Сорри бро, инглиш ис зе праймари ленгвидж оф зе девелопмент ворлд
@@zhukovsd_it_mentor it is other)
Таки салюшен начинается с нефункциональных требований про них не сказано ничего или вскользь. Сколько пользователей, сколько курьеров, где разворачиваемся (aws, azure, ), надежность, доступность, как и кто поддерживает после релиза и прочее. Без этого проектировать бессмысленно. Есть очень хороший плейлист у Interview Pen так и называется system design.
Мне ещё нравится канал System Design Fight Club.
Но моё видео немного не про это, а про ход мыслей при проектировании бизнес логики и компонентов пет-проекта на тему доставки еды.
На эту тему нужно в начале видео озвучивать дисклеймер, спасибо за комментарий.
9:50 Начало
как найти ещё такие видео или контент?
Привет) У меня вопрос, почему оплата заказа через платежку происходит до подтверждения рестораном о готовности выполнить этот заказ ? :) теоретически это довольно частый кейс но для клиента это очень неприятная история, списание денег и после ожидание их возврата в течении како го то времени, особенно если речь идет о днях.
у всех агрегаторов доставок так сделано
Остановил ролик после проектирования бд. Очень поверхностное проектирование вообще при довольно сложной темы как агрегатор доставки еды. А номер позиции в меню? А категория блюда? А правила для заказа (минимум ценик заказа, расстояние между клиентом - рестораном )? А возможность убрать ингредиент? А если сеть ресторанов? А как сама агрегация ресторанов будет происходить? А возможность отзыва? и тд тп... уж лучше сделали подробно онлайн заказ у одного ресторана.
ТЗ уровень описания того самого клиента на фриланс платформе, который не понимает что хочет и ничего толком не знает (сто пудов кинет и у него будут круглые глаза когда узнает сроки\цену). Ну и хранение постоянно меняющееся coorinates курьера в холодном хранилище, даже теоретически, конечно убило.
Замечания по делу, спасибо 👍