- Food delivery Service System Design - Phase 2 "Local Market"
- Key requirements (Architectural drivers)
- Structural context
- Container view
- Technology Stack
- Deployment view
- Security
- Risks
- Architecture Decision Records
- Constants
В период локдауна услуги по доставке еды мгновенно взлетели до небес. Все стремились получить необходимые продукты и блюда, доставленные к порогу дома. Таким образом, период карантина открыл широкие возможности для бизнеса доставки еды.
Хотя может показаться, что гиганты индустрии контролируют рынок, это не совсем так. Во время пандемии по всему миру стали появляться стартапы по доставке еды по требованию, и они до сих пор набирают популярность.
Glovo, испанский стартап, который сотрудничает предприятиями для доставки еды из ресторанов, продуктов и других товаров, получил финансирование в размере 528 миллионов долларов. Аналогичным образом, Gousto, британский сервис по доставке наборов еды, привлек 41 миллион долларов во время пандемии.
Gorillas, продуктовый стартап, цель которого - доставка товаров за десять минут или меньше, привлек 290 миллионов долларов, превысив первоначальную оценку в 1 миллиард долларов.
Рынок доставки готовой еды и бакалеи начал развиваться в Казахстане около 4 лет назад. На динамику его роста повлияли:
- появление крупных международных игроков на рынке в 2019 году;
- пандемия Ковид-19, которая изменила покупательские привычки и операционные решения компаний.
Большинство из этих услуг доступны во всех крупных городах Казахстана - Алматы, Астане, Шымкенте, Усть-Каменогорске, Караганде, Таразе и других. В небольших городах службы доставки распространены меньше.
Тренд на доставку в регионах только зарождается в Казахстане - интернет-магазины и доставка из ресторанов слабо представлены в регионах. И это является точкой роста для рынка.
- Ожидается, что в 2024 году рынок доставки еды в Казахстане будет приносить доход в размере 53,80 млн долларов США.
- Согласно этому прогнозу, совокупный годовой темп роста (CAGR 2024-2028) составит 7,97%, в результате чего к 2028 году объем рынка составит 73,11 млн долларов США.
- Что касается рынка платформ доставки, размер рынка в Казахстане, по прогнозам, достигнет 26,98 млн долларов США в 2024 году.
- Однако, по сравнению с другими странами, наибольший доход ожидается в Китае, где он составит 182 900,00 млн долларов США в том же году.
- Средний доход на одного пользователя (ARPU) на рынке доставки еды в Казахстане составит 32,58 доллара США в 2024 году.
- Ожидается, что к 2028 году количество пользователей на рынке доставки еды достигнет 2,2 миллиона человек.
- С точки зрения проникновения пользователей, рынок доставки еды в Казахстане достигнет 8,4% в 2024 году.
- Несмотря на растущую популярность услуг по доставке еды в Казахстане, традиционная домашняя еда по-прежнему доминирует на рынке.
Сравним крупнейших игроков на казахстанском рынке: Wolt, Glovo, Chocofood и Yandex Food.
1st place
10 заведений назвали эту услугу самой популярной среди своих клиентов.
Рестораны объясняют популярность этого сервиса тем, что он удобнее для их пользователей, чем другие сервисы. Поэтому большинство заведений ставят его на 1-е место в своем личном рейтинге. Стоит также отметить, что стоимость доставки этой службы может быть гораздо дешевле, чем заказ такой же доставки из самого заведения. Услуга GLOVO представлена в 20 из 21 опрошенных заведений.
2nd place
9 заведений назвали этот сервис самым популярным среди своих клиентов.
Слишком маленький отрыв от первого места, что может говорить об похожем удобстве и скорости работы сервиса! А главным преимуществом является бесплатная доставка, которая теперь доступна в сервисе, а также вы можете получить кешбэк в размере 30% при оплате картой VISA. Это очень серьезное преимущество перед конкурентами. Сервис WOLT представлен в 18 из 21 опрошенных заведений.
3rd place
2 ресторана высказались как о самой популярной услуге среди своих клиентов.
Давно известный и любимый многими жителями Алматы, остается в рейтинге довольно высоким, по той причине, что его использование уже стало очень привычным, а в зависимости от района проживания иногда самым интересным и быстрым предложением. Стоимость доставки невысока, а в некоторых местах даже предлагается абсолютно бесплатная доставка при заказе через этот сервис. Услуга Chocofood представлена в 17 из 21 опрошенного заведения.
4th place
Ни один ресторан не назвал эту услугу самой популярной среди своих клиентов.
Даже учитывая популярность этой услуги, к сожалению, она не имеет плюсов и преимуществ для клиентов. Цена за доставку напрямую зависит от расстояния, что также не может радовать. Поэтому на данный момент эта услуга менее популярна. Зато Яндекс может привезти заказ в любую точку, куда вы пожелаете. Это удобно для тех, у кого нет другого выхода. Сервис Яндекс Еда представлен в 13 из 21 опрошенного заведения.
На рынке Казахстана есть и другие менее популярные службы доставки, на которые вы также можете обратить свое внимание, учитывая, что некоторые из них могут быть ближе к вам, а значит, быстрее привезут вам заказ.
Мы собираемся запустить онлайн-платформу доставки еды, которая позволит потребителям, ресторанам и службам доставки взаимодействовать в режиме реального времени. Мы должны поддерживать как мобильные приложения для всех клиентов, так и веб-приложение для административных функций. Мы уверены, что станем следующим большим и популярным проектом, и ожидаем значительного и быстрого роста в ближайшие несколько лет.
Мы предполагаем три значимые вехи развития:
- MVP решение на коленке, чтобы прощупать рынок на одного из регионов Казахстана, собрать команду и отработать основные технологические решения.
- Масштабировать решения на рынок Казахстана, обеспечить стабильность сервиса и явные конкурентные преимущества.
- Обеспечить возможности для быстрого выхода на другие рынки.
- SH-1: Клиент
- Понятный и простой пользовательский интерфейс
- Полезные услуги
- Быстрая и недорогая доставка
- Большое количество ресторанов и блюд
- SH-2: Ресторан
- Простое в использовании веб-приложение с каталогом блюд
- Быстрая доставка еды
- Минимальное количество проблем для клиентов
- SH-3: Курьер
- Простое в использовании мобильное приложение
- Высокая стоимость доставки
- SH-4: Администратор (из нашей компании)
- Привлечение различных типов клиентов
- Повышение качество предоставляемых блюд и услуг
- Открытие новых ниш для развития бизнеса
- SH-5: Служба поддержки
- Легкий доступ к информации о падениях услуг, ошибках и исключительных ситуациях
- SH-6: Разработчик
- Упрощение разработки и поддержки системы
- SH-7: Системный администратор
- Удобные средства мониторинга
- Удобные средства конфигурирования и масштабирования
- ASN-1: В период между открытием и закрытием ресторана можно есть неограниченное количество еды. Таким образом, нет необходимости проверять количество доступных блюд. Не требуется управление запасами.
- ASN-2: У ресторанов нет собственной системы/инфраструктуры онлайн-заказа, все заказы они будут принимать только у нас.
- ASN-3: Клиентам будут показаны рестораны в определенном радиусе, скажем, 10 километров.
- ASN-4: Клиенты могут заказывать еду только из одного ресторана одновременно в онлайн-заказе. Пункты меню из нескольких ресторанов не могут быть объединены в одном заказе.
Ниже показано схематичное высокоуровневое описание всего жизненного цикла клиента включая регистрацию всех участников на платформе, формирование заказа, оплату заказа, уведомление ресторана о появлении нового заказа в системе и доставку готовых блюд клиенту.
Жизненный цикл представляет собой следующие шаги:
- Регистрация/вход в систему: Клиенты, рестораны и курьеры могут зарегистрироваться в приложении, указав свои имена, номера телефонов, идентификаторы электронной почты и пароли. Они могут войти в систему, если были зарегистрированы ранее.
- Список ресторанов: Клиентам предлагается список ресторанов, расположенных поблизости от их местонахождения. Они также могут искать конкретные рестораны по различным атрибутам.
- Размещение заказа: Клиенты могут сделать заказ в любом из перечисленных ресторанов, указав адрес доставки.
- Обработка платежей: Клиенты могут оплачивать свои заказы через любой из многочисленных платежных шлюзов приложения.
- Уведомление ресторанов: Ресторан получает уведомления о новом заказе
- Назначение заказов курьерам: Курьеры могут принимать или отклонять отправленные им запросы на доставку еды. В случае принятия они отправляются в рестораны, чтобы забрать заказ для доставки.
- Отслеживание заказов: Клинеты могут отслеживать состояние своего заказа до тех пор, пока он не будет доставлен.
- Рейтинги и отзывы: После получения заказа клиенты могут оценить и просмотреть блюда и услуги доставки.
Чтобы создать успешную платформу доставки еды, нам нужен надежный план. Ниже приведен перечень шагов для реализации фазы №1.
На этом этапе мы должны исследовать рынок, определиться с бизнес-моделью и функциями частей нашей платформы доставки еды и разработать достаточный объем кода для запуска MVP на небольшом локальном рынке.
Шаг 1. Исследование рынка
Необходимо тщательно изучить, что нравится клиентам, какие тенденции наблюдаются в отрасли и кто является нашим конкурентом. Найдите пробелы на рынке и воспользуйтесь этими возможностями. Это поможет нам лучше понять целевую аудиторию и выделить ваше приложение в индустрии доставки еды.
Шаг 2. Определить уникальные преимущества нашего приложения
Определить, что отличает наше приложение для доставки еды от существующих конкурентов. Сосредоточиться на решении конкретных проблем клиентов, таких как более быстрая доставка, разнообразные фильтры приложения или более удобный интерфейс.
Шаг 3. Выбор бизнес-модель
Перед началом разработки приложения для доставки еды необходимо выбрать бизнес-модель, которая соответствует нашим целям и целевой аудитории. Мы можем выбрать такие варианты, как партнерство с ресторанами или, например, готовое решение для них.
Шаг 4. Выбрать подход как мы будем осуществлять разработку системы
Лучше всего осуществлять разработку ключевых доменов решения собственными силами и отдать supportive и general домены на подряд надежной компании с опытом разработки, либо использовать проверенные временем продукты.
Шаг 5. Определиться с функциями приложения
Изучив рынок, нужно определить, что делает наше приложение особенным. Возможно, у нас уже есть идея идеального приложения для доставки еды, но необходимо последовательно изучать рынок и выявлять наиболее ценные свойства решения за которые клиенты будут платить.
Шаг 6. Выбрать технологический стек
Необходимо выбрать подходящий технологический стек, включая платформу (iOS, Android или обе), инфраструктуру бэкенда и управление базами данных. Выбор в том числе зависит от имеющихся у нашей команды компетенций.
Шаг 7. Дизайн и разработка приложения
Необходимо создать интуитивно понятный и удобный дизайн приложения. Не стоит забывать о пользовательском опыте, чтобы сделать приложение для доставки еды простым в использовании.
Шаг 8. Безопасная интеграция платежей
Необходимо использовать надежные средства защиты для обработки платежей, чтобы обеспечить безопасность данных пользователей. Это защитит пользователей и повысит доверие к вашему приложению для доставки еды.
Чтобы создать успешную платформу доставки еды, нам нужен надежный план. Ниже приведен список шагов Фазы №2 проекта.
На этом этапе мы уже определились с бизнес-моделью и функциями нашей платформы запустили MVP на небольшом локальном рынке. Далее необходимо составить конкуренцию во всех крупнейших городах страны и начать захватывать региональный рынок. Для этого необходимо
Шаг 1. Определить состав технического долга
Необходимо посмотреть на бэклог задач, которые описывают блоки функционала требующие рефакторинга. Далее необходимо оценить необходимый объем ресурсов для устранения технического долга.
Шаг 2. Тестирование приложения для масштабирования
Обязательно нужно потратить ресурсы на покрытие важных частей кода автотестами и на тщательное тестирование приложения, чтобы команда разработчиков могла выявить и устранить любые ошибки или проблемы. Тестирование включает в себя проверку работоспособности всех функций, обеспечение правильного ввода и вывода данных, совместимость с различными устройствами и операционными системами. Кроме того, необходимо выделить ресурсы на проведение нагрузочного тестирования.
Шаг 3. Актуализировать архитектурные решения
На данном шаге наша система представляет собой неоптимальное с точки зрения архитектуры решения. На предыдущем этапе у команды разработки не было задачи обеспечить возможность кратного роста количества пользователей платформы, обеспечение максимальной безопасности данных и возможности масштабирования разработки и удобной интеграции с партнерами.
Шаг 4. Обеспечение гибкости разработки
Кодовая база платформы на этом шаге может значительно вырасти, появится несколько независимых команд, причем возможно команды будут использовать отличный от основного технический стек. Необходимо обеспечить поддержку возможности независимой разработки, интеграции и деплоя своих фич для каждой команды.
Шаг 5. Документирование решения
На данном шаге наша система не покрыта нормальной документацией, поскольку для стадии MVP в этом нет острой необходимости. Команда небольшая и кодовая база также понятна. На втором шаге возможно масштабирование команды и подключение партнеров и сторонних команд к проекту, поэтому хорошая документация становится необходимым условием работы.
Чтобы создать успешную платформу доставки еды, нам нужен надежный план. Ниже приведен список шагов Фазы №3 проекта.
На этом этапе необходимо подготовить разработанную платформу для ввода в эксплуатацию за пределами локального рынка. На данном шаге значительно повышаются требования к локализации решения, простоте эксплуатации и развертывания в публичном облаке. Также необходимо учитывать особенности каждого рынка с точки зрения законодательства, национальных традиций и использования данных.
Шаг 1. Актуализировать архитектурные решения
Определить ключевые архитектурные характеристики решения для глобального рынка доставки еды.
Шаг 2. Мультиязычность и локализация
Нужна поддержка нескольких языков. Это включает в себя интернационализацию наших мобильных и веб приложений, чтобы они могли поддерживать новые языки, а также локализацию контента и интерфейса под нужды конкретных рынков.
Шаг 3. Мультивалютность
Необходимо обеспечить поддержку различных валют для обработки платежей и отображения цен для нашей платформы.
Шаг 4. Глобальная доступность и производительность
Требуется перевести инфраструктуру в облако, которое обеспечит высокую доступность и производительность вашей платформы для пользователей из разных стран. Необходимо обеспечить мультизональность в облаке, чтобы уменьшить задержки и обеспечить быструю загрузку страниц.
Шаг 5. Безопасность и конфиденциальность данных
Платформа доставки еды должна соответствовать международным стандартам безопасности данных, например таким как GDPR для стран Европейского Союза или CCPA для Калифорнии. Нужно обеспечить защиту конфиденциальности данных пользователей и соответствие местным законам о защите данных.
Шаг 6. Географическое распределение данных
Необходимо использовать географически распределенных баз данных или CDN (сети доставки контента) для обеспечения быстрого доступа к данным для пользователей из разных стран.
Мы собрали все обязательные функции, которыми должно обладать приложение для доставки еды для клиентов, владельцев ресторанов и водителей. Давайте разберемся.
Клиенты:
- FR-1: Поиск ближайших ресторанов на основе местоположения пользователя. Пользователи также могут посмотреть меню, цены, отзывы и заказать еду из ресторана.
- FR-2: Создание корзины, добавление в нее блюд из меню и формирование заказа.
- FR-3: Получение уведомлений о статусе заказа после его оформления
- FR-4: Отслеживание статуса заказа в приложении
- FR-5: Проверка, сколько времени потребуется курьеру на доставку
- FR-6: Отмена заказа
- FR-7: Осуществление онлайн-платежа с помощью дебетовых/кредитных карт, интернет-банкинга и т.д.. С другой стороны, рестораны могут легко получить деньги через интеграцию с платежными шлюзами, такими как Kaspi, Stripe и т. д.
- FR-8: Оценка приложения или услуги, чтобы администраторы могли решить проблемы и повысить уровень сервиса
- FR-9: Возможность клиенту управлять и просматривать свои прошлые заказы. И возможность повторить предыдущие заказы, когда это необходимо
- FR-10: Создание/обновление учетной записи и контактной информации
Рестораны:
- FR-11: Создание профиля (onboarding) и создание/обновление/добавление новых пунктов меню, фотографий, цен и наличия
- FR-12: Получение уведомлений о размещенных заказах, назначенных водителях, актуальном статусе заказа и т. д.
- FR-13: Управление оплатой и комиссионными за каждый заказ еды
- FR-14: Offboarding: Если ресторан выходит из бизнеса или решает прекратить прием онлайн-заказов
Курьеры:
- FR-15: Регистрация и авторизация в приложении, используя номера телефонов, различные социальные сети. Вся процедура регистрации или входа должна быть простой, чтобы новые участники могли легко зарегистрироваться.
- FR-16: Загрузка личной информации в профиль, такой как имя, адрес электронной почты, контактные данные, фотография и других данных.
- FR-17: Оповещение курьеров о новых заказах, которые были назначены. Когда водители не используют приложение для доставки, они должны получать звуковое оповещение о заказах, которые были запрошены.
- FR-18: Обработка и реагирование на различные запросы для доставки еды. Курьеры могут принимать любые заявки, которые находятся недалеко от другого места доставки.
- FR-19: Интеграция с картами GPS.
- FR-20: Управление оплатой и комиссионными для каждого заказа еды.
- FR-21: Информация, когда заказ доступен для доставки.
- FR-22: Информирование клиента и ресторан о любых проблемах, возникающих при выполнении заказа.
- FR-23: Если у клиента возникла проблема, курьер может воспользоваться чатом или звонком, чтобы связаться с ним и позвонить.
- FR-24: Возможность просмотреть историю заказов на доставку еды и записи об оплате.
- FR-25: Возможность расторгнуть контракт и прекратить оказывать услугу
Администраторы:
- FR-26: Каждое действие, выполняемое клиентами или курьерами в приложении для доставки еды, может контролироваться администратором. Приборная панель администратора позволяет отслеживать доставку еды, курьеров и запланированные/отмененные заказы, а также получать доступ к информации о курьерах.
- FR-27: Администратор может управлять всем: от получения посылок с едой до доставки и запланированных заказов. Администраторы отвечают за упрощение заказов и их доставку клиентам в определенное время.
- FR-28: Обновления и уведомления в реальном времени о курьерах и владельцах ресторанов, например, обновление их профиля, расписания работы ресторанов и доступности.
- FR-29: Позволяет администратору предлагать различные скидки и коды купонов в приложении.
- FR-30: Оповещения и уведомления о том, что курьер принял заявку на заказ и направляется на сбор/доставку посылок.
- FR-31: Возможность администратору добавлять и удалять рестораны из приложения.
- FR-32: Возможность запускать и управлять различными кампанииями по электронной почте, SMS и в социальных сетях.
Ниже перечислены глобальные ограничения для решения для фазы "Local", которые определяют все компромиссные решения:
- NFR-B1: Общая база клиентов "Билайн" - около 20 млн.
- NFR-B2: Потенциальные клиенты службы доставки еды - около 2М
- NFR-B3: Активные пользователи сервиса - около 500K
- NFR-B4: Предположим, мы обслуживаем пользователей в 20 городах.
- NFR-B5: В среднем в каждом городе может быть 200 ресторанов.
- NFR-B6: Общее количество ресторанов: 4K
- NFR-B7: В каждом ресторане может быть 30 блюд, которые могут быть поданы.
- NFR-B8: Общее количество блюд = 4000 * 30 = 120K
- NFR-B9: Общее количество агентов доставки: 1K
- NFR-B10: Средний чек - 4500 тенге
- NFR-B11: Каждый клиент в среднем делает 1 заказ в день, то количество заказов в день = 500К
- NFR-B12: Как долго хранить информацию о клиентах - 5 лет
- NFR-B13: Как долго хранить информацию о ресторанах и меню - 3 года
- NFR-B14: Как долго хранить информацию о заказах - 5 год
- NFR-B15: Пиковое время заказов обычно зависит от дня недели. Например, в выходные дни может быть больше заказов, чем в будни. Пиковое время может приходиться на полдень или обед в каждом регионе. Пик - это 200 тыс. заказов в час.
- NFR-B16: В целом, поиск меню/ресторанов будет связан с чтением, а функции заказа - с записью. Вероятность того, что клиенты будут просматривать прошлые заказы после того, как они были доставлены и еда была съедена, очень мала.
- NFR-B17: Доступность системы должна составлять 99,9 %
Ключевые архитектурные характеристики, которые были определены на этапе развития платформы в нескольких городах Казахстана, помогают нам определить общий архитектурный стиль. Три наиболее важные характеристики выделены жирным шрифтом:
- Agility ++
- Scalability ++
- Availability +
- Performance
- Interoperability
- Usability
- Reusability
- Maintainability
- Modularity ++
- Data Integrity
- Security +
- Cost
- Configurability
- Fault Tolerance +
- Simplicity
Выделенные выше ключевые архитектурные характеристики позволяют определить наиболее подходящий архитектурный стиль на данном этапе.
Ниже показан концептуальный дизайн системы Food Delivery. Более подробную информацию о C4 Model можно найти в официальной документации.
Цель разработки диаграммы на уровне контекста - показать область применения разработанной программной системы (показана в центре) и указать, с какими внешними объектами взаимодействует система.
В ходе нескольких сессий Event Storming были выявлены основные домены разрабатываемой системы. Event Storming - это гибкий формат семинара, который позволяет командам совместно исследовать сложные бизнес-области. Он особенно эффективен для объединения заинтересованных сторон с разным опытом и специализацией. Методология может быть адаптирована к различным сценариям.
Выявленные субдомены разрабатываемой системы включают:
- Core domain
- Delivery service
- Restaurant service
- Customer service
- Administration service
- Order service
- Supportive domain
- Accounting service
- Feedback service
- Generic domain
- Reporting service
- Payment service
- Notification service
- Auth service
На рисунке ниже представлено наше видение доменной структуры решения.
На рисунке ниже представлено видение классификации основных, поддерживающих и общих доменов.
Core domain
Обеспечивает уникальность бизнеса и самые важные бизнес-процессы. В нашем случае это:
- Delivery service
- Наполнение профиля курьера
- Управление доставкой заказов
- Restaurant service
- Управление меню ресторана и другой информацией, включая местоположение и часы работы
- Просмотр заказа в ресторане (управление приготовлением заказов на кухне ресторана)
- Customer service
- Онбоардинг клиента
- Управление информацией о клиентах
- Представление заказа клиентом (управление инвариантами заказа и клиента, например, лимитами заказа)
- Administration service
- Управление информацией о клиентах
- Мониторинг всех событий связанных с клиентами, ресторанами и курьерами
- Order service
- Управление заказами и выполнением заказов
Supportive subdomain
Значимо для бизнеса, но могут быть использованы сторонние программные продукты при соответствующей настройке и интеграции. В нашем случае это:
- Feedback service
- Система должна быть легко расширяемой и может включать механизмы опроса других производителей.
- Модуль предоставляет удобный способ управления каналами обратной связи.
- Accounting service
- Учет потребителей - управление выставлением счетов потребителям
- Бухгалтерия ресторана - управление платежами ресторанам
- Учет курьеров - управление платежами курьерам
Generic subdomain
Для модулей, которые попадают в эту категорию, не требуется никакой или незначительной доработки - все потребности покрываются другими программными продуктами, доступными на рынке.
- Reporting service - нет необходимости внедрять собственный механизм создания отчетов, поскольку многие специализированные продукты могут создавать все необходимые отчеты на основе предоставленных данных.
- Payment service - мы лишь создадим шлюз для платежных систем или даже выберем платежного провайдера, который будет осуществлять все специфические коммуникации с платежными системами.
- Notification service - лучше использовать готовые сервисы, которые их предоставляют, чтобы сэкономить время и деньги.
- Auth service - можно точно использовать готовые проверенные решения для аутентификации и авторизации
Диаграмма Container показывает элементы внутри системы Food Delivery Platform и то, как они связаны друг с другом, а также с акторами и внешними системами. Домены внутри системы далее разбиваются на диаграммы компонентов на следующем уровне. Диаграмма контейнеров скрывает детали реализации, чтобы увидеть общую картину.
API Gateway
API Gateway - это сервис, который предоставляет единый точку входа для доступа к множеству наших микросервисов через API (интерфейсы программирования приложений). Он выполняет ряд функций, включая маршрутизацию запросов, преобразование данных, кэширование, мониторинг и другое. Его назначение - скрытие сложность архитектуры микросервисов от фронтов за одним удобным программным интерфейсом. Он также обеспечивает централизованное управление и контроль за всеми API, что улучшает безопасность, масштабируемость и производительность приложений.
Auth Service
Keycloak - это открытое программное обеспечение для управления доступом и идентификации, разработанное компанией Red Hat. Оно предоставляет функциональность управления аутентификацией, авторизацией и управлением сеансами для веб-приложений и микросервисов.Кроме того, Keycloak предоставляет средства для управления пользователями, ролями и политиками безопасности. Он широко используется в корпоративных средах для обеспечения безопасности и управления доступом к приложениям и сервисам. Нам удобно использовать в промышленном решении именно Keycloak.
Customer Service
Это один из ключевых сервисов архитектуры системы, который предназначен для управления информацией о клиентах, их профилях, заказах, истории взаимодействия и других связанных данных. Он предоставляет API для доступа к этим данным, а также реализует логику, связанную с обработкой запросов, связанных с клиентами, таких как аутентификация, авторизация, обновление профилей и т. д. Customer Microservice обеспечивает изолированный и масштабируемый способ управления клиентской информацией, что упрощает разработку, масштабирование и обслуживание приложений, использующих этот функционал.
Restaurant Service
Сервис предназначенный для управления операциями, связанными с функционированием ресторана. Этот микросервис включает функционал, связанный с управлением меню, обработкой заказов, управлением столами, учетом ингредиентов и запасов, управлением персоналом и другими аспектами, характерными для работы ресторанного бизнеса.
Delivery Service
Это компонент архитектуры, который специализируется на управлении операциями доставки продуктов или услуг. Этот микросервис включает функционал, связанный с управлением заказами на доставку, расписанием доставки, отслеживанием статуса заказа, управлением водителями и маршрутами доставки, а также взаимодействием с клиентами по вопросам доставки.
Order Service
Этот микросервис включает функционал для приема заказов от клиентов, обработки платежей, управления состоянием заказа, генерации уведомлений о статусе заказа, а также интеграции с другими компонентами системы, такими как Restaurant Service, Delivery Service, и т. д.
Administration Service
Данный микросервис обеспечивает бизнес-логику для отслеживания заказа по всем этапам жизненного цикла, начиная от размещения блюда в меню ресторана, заканчивая его доставкой клиенту.
Feedback Service
Предназначен для управления обратной связью от пользователей или клиентов. Этот микросервис содержит функционал для сбора отзывов, оценок, комментариев и других форм обратной связи от пользователей в отношении продуктов, услуг или процессов. Он также предоставляет функции анализа и обработки полученной обратной связи, генерации отчетов и уведомлений о новых отзывах.
Reporting Service
Включает функционал для агрегации данных из различных источников платформы, обработки информации, форматирования и представления данных в виде отчетов или дашбордов. Reporting Service предоставляет возможности для настройки отчетов, автоматического расписания их генерации, а также опциональных функций распространения и экспорта отчетов в различные форматы.
Notification Gateway
Обеспечивает единый интерфейс для отправки уведомлений клиентам, курьерам и ресторанам через различные каналы связи, такие как электронная почта, SMS, push-уведомления и другие. Он предоставляет абстракцию над различными провайдерами уведомлений и обеспечивает стандартизацию процесса отправки сообщений.
Payment Gateway
Обеспечивает абстракцию между Order Service и различными платежными системами. Он позволяет осуществлять электронные платежи, обрабатывая информацию о кредитных картах, банковских счетах или других формах онлайн-платежей. Payment Gateway обеспечивает безопасность транзакций, шифруя данные платежей и управляя процессом авторизации и обработки платежей между клиентом, продавцом и платежным процессором.
Чтобы не усложнять проект я намеренно не выделяю такие сервисы, как:
- Landing pages
- Финансы и все что с этим связано
- Сервисы поддержки
- Сервисы уровня сети
Различные сервисы платформы подключаются через API-шлюз. Этот шлюз обеспечивает балансировку нагрузки и маршрутизацию запросов к соответствующим сервисам.
- Такие сервисы, как Auth Service, Order Service, Administration Service и Delivery Service, используют реляционную базу данных PostgreSQL.
- Информация о ресторанах, меню, ценах и предложениях будет храниться в MongoDB, хранилище документов JSON, которое обеспечивает быстрый и масштабируемый поиск по неструктурированным данным. Это позволит клиентам быстро находить меню и блюда. Также для улучшения отзывчивости сервисов можно использовать Redis для промежуточного кэширования данных.
- Процесс оформления заказа осуществляется через Order Service и включает в себя выбор блюд, расчет цен и обработку платежей через Payment Gateway. Справочную информацию сервис получает у других сервисов синхронным образом через REST API, нотификации на различных этапах жизненного цикла заказа отправляются в центральную очередь сообщений RabbitMQ.
- Клиенты получают push-уведомления и SMS о своих заказах и могут отслеживать статус заказа и местоположение курьера через Customer Service и отслеживания заказов.
- Затем курьер забирает заказ и доставляет его клиенту с уведомлением о предполагаемом времени прибытия в режиме реального времени. Для этого используется Delivery Service, который взаимодействует с Order Service через брокер сообщений.
- Администратор также может формировать отчеты и делать аналитику через Reporting Service. Для этого сервиса использована колоночная БД Clickhouse.
https://databasediagram.com/app
На рисунке выше представлен вариант разделение БД монолита на отдельные хранилища для каждого микросервиса (каждый цвет соответствует отдельному микросервису). Выбор базы данных для каждого микросервиса будет обусловлен объемом хранимых данных, удобства масштабирования, степени структурированности данных, удобства репликации и ряда других факторов.
На данном этапе планируется использовать три вида СУБД:
- PostgreSQL для транзакций и структурированных данных
- MongoDB - для слабоструктурированных данных
- Clickhouse - колоночная СУБД для аналитики
Чтобы проектирование системы было эффективным, нам нужно знать, с каким объемом данных мы работаем.
В соответствии с указанными требованиями в разделе “Quality attributes and scenarios” мы имеем следующие цифры на фазе внедрения платформы на рынке Казахстана:
- Потенциальные клиенты службы доставки еды - около 11M
- Активные пользователи сервиса в Казахстане - около 500K
- Всего 4K ресторанов
- В каждом ресторане может быть 30 блюд
- Общее количество блюд = 4K * 30 = 120K
- Общее количество агентов доставки: 1K
- Количество заказов в день = 500K
Предположим, что на данном этапе в нашу платформу доставки еды ежемесячно будет добавляться 20 новых ресторанов и 500 новых клиентов. Соответственно, можно рассчитывать на 10*30 новых блюд в месяц.
Предположим, что информацию о ресторанах, курьерах и клиентах и заказах необходимо хранить не менее 5 лет.
Примерный объем хранимой информации в первый год будет следующим:
- Профили клиентов, курьеров и менеджеров ресторанов: 1148 GiB
- Данные о ресторанах и меню: 28 GiB
- Данные о блюдах: 46 GiB
- Данные о курьерах: 588 MiB
- Данные о заказах: 396 GiB
- Данные нотификаций: 26 GiB
- Данные для аналитики: 217 GiB
- Итого: 5,7 TiB
- plus Репликация данных 3х: 17 TiB
Примерный объем хранимой информации за 5 лет: 85 TiB + 10% = 90 TiB
| Topic | Android | iOS |
| Programming Languages | Java, Kotlin | Swift, Objective-C |
| Toolkit | Android Studio, Android Developer Tools | Apple Xcode |
| SDK | Android SDK | iOS SDK |
| Topic | Technology |
| Programming Languages | Typescript |
| Library or Framework | React, Redux
Next |
| Topic | Technology |
| Programming Languages and frameworks | Java, Spring
Liquibase Python, FastAPI |
| Orchestrator | Kubernetes |
| Virtualization platform | VMware |
| Relational data store | PostgreSQL |
| Documents store | MongoDB |
| Column data store | Clickhouse |
| Objects store | MinIO |
| Cache | Redis |
| Auth | Keycloak |
| API gateway | KrakenD |
| Message broker | Apache kafka, RabbitMQ |
| Orchestration | Kubernetes |
| Monitoring | Prometheus, Grafana |
| Logging | FluentD, ElasticSearch, Kibana |
| Secrets Manager | Vault |
| Images repository | JFrog |
| Ci/CD | Gitlab |
| Topic | Services | Integration type |
| Mailing Services | MailGun,Firebase Cloud Messaging | REST, JSON |
| Push Notifications | Apple Push Notifications Service (APN), Firebase Cloud Messaging (FCM) | REST, JSON |
| Social Media | Twitter, Facebook, Instagram | REST, JSON |
| Payments | Stripe,Google Pay, Apple Pay, Kaspi Pay | REST, JSON |
| Location Tracking | MapKit for iOS
Yandex Maps 2Gis |
REST, JSON |
| Internal integrations | Auth Service
Customer Service Restaurant Service Delivery Service Order Service Administration Service Feedback Service Reporting Service Notification Gateway Payment Gateway |
REST, JSON
GraphQL AMQP, JSON |
На этапе работы на локальном рынке используется средства виртуализации на базе VMWare для систем хранения данных и обмена сообщениями, а также кластер K8S для контейнеризации приложений.
Оркестрация контейнеров реализована в K8S, настроены средства автоматического масштабирования в случае повышения нагрузки на систему.
Для систем хранения данных и систем обмена сообщениями предусмотрена репликации.
Администраторы могут получить доступ к данным кредитных карт клиентов. Необходимо предотвратить это, выделив биллинг в отдельный архитектурный квант и изолировав его в отдельной сетевой зоне со строгими разрешениями на доступ.
То же самое касается и службы поддержки клиентов - мы не хотим, чтобы злоумышленник получил доступ к перезагрузке системы. Значительным улучшением безопасности будет перенос клиентских сервисов и данных в отдельный сегмент и изоляция его в отдельной сетевой зоне.
Существует множество аспектов безопасности, которые необходимо учитывать, включая аутентификацию и авторизацию. Ниже приведен обзор соображений безопасности для решения, которое будет разработано.
Для сетевого трафика можно применять тонкие политики безопасности, что особенно важно при взаимодействии с другими системами. В рамках платформы мы можем их использовать для создания Zero Trust инфраструктуры, которая поможет защититься от злоумышленников, которые потенциально могли бы обойти систему аутентификации.
Необходимо использовать сервисы:
- Защита от DDoS-атак
- Брандмауэр веб-приложений - фильтрация вредоносного трафика и обеспечение нулевого доверия
Необходимо использовать механизмы шифрования и управления ключами, что позволяет обеспечить дополнительный уровень защиты данных и не хранить секретные данные в коде.
Данные будут зашифрованы в состоянии хранения (например, в базе данных) и при передаче (внутри системы, а также при входе в систему и выходе из нее) с использованием надлежащего надежного шифрования.
Пароли будут храниться только в виде хэшей, а политика в отношении длины и сложности будет соответствовать современной практике (например, 10+ символов, не менее 256 символов, не нужно включать определенные типы символов, проверять списки взломанных/обычных паролей, не нужно менять каждые x месяцев и т. д.).
Используемые технологии:
- HTTPS/SSL - TLS для обеспечения безопасности соединения. Все коммуникации между веб- или мобильными клиентами должны осуществляться по TLS.
- OAuth 2.0 для авторизации/обновления/генерации токенов.
Используемые службы:
- Key Management Service - хранение и управление ключами шифрования
- Certificate Manager - управление публичными и частными сертификатами SSL/TLS
- Secrets Manager - управление, ротация и извлечение секретов
Необходимо обеспечить непрерывный мониторинг сетевой активности и поведения учетных записей/пользователей, чтобы выявлять угрозы при первой же возможности.
Используемые решения:
- Системы управления информационной безопасностью (SIEM): собирают, агрегируют, анализируют и отображают данные о безопасности из различных источников, таких как журналы событий, сетевые устройства, конечные точки и т. д. Эти системы могут обнаруживать аномалии, атаки и другие потенциальные угрозы на основе анализа больших объемов данных.
- Системы обнаружения вторжений (IDS/IPS): контролируют сетевой трафик и обнаруживают атаки, аномальные попытки доступа и другие угрозы. Они могут быть развернуты как на периметре сети, так и внутри сетевой инфраструктуры для защиты различных уровней сетевой архитектуры.
- Ведение журнала и отслеживание активности
- Восстановление после сбоев или вредоносных атак
Это возможные деловые и технические риски, которые мы постарались осветить ниже.
- BR-1: Существуют достаточно сильные конкуренты на рынке. Они уже утвердили свои ниши и у них достаточно много лояльных клиентов.
- BR-2: Не каждый наш клиент может себе позволить доставку готовой еды каждый день. Нужно понять, какой стоимость доставки и какими блюдами мы можем привлечь максимальное количество клиентов.
- BR-3: Бездомные и малообеспеченные люди не смогут воспользоваться системой.
- BR-4: Возможны проблемы с качеством пищи в ресторанах. Нужно подключить юристов, чтобы минимизировать связанные с этим риски.
- BR-5: Люди могут воспринять новый сервис негативно и запустить антирекламу в социальных сетях.
- CR-1: Проблемы с качеством пищи предлагаемой на платформе могут нанести ощутимый вред здоровью части абонентов.
- CR-2: Возможная утечка личной информации из профиля клиента (см. раздел "ADR-2 Security").
- TR-3: При увеличении числа пользователей возможно появление различного рода фродовых операций, которые сложно выявить.
- TR-1: Риск значительного увеличения нагрузки на систему во время некоторых маркетинговых кампаний. Это связано с тем, что мы не можем предсказать количество регистраций.
- TR-2: Реализовать на старте проекта качественные мобильные и веб-приложения может быть довольно сложно. Требуется тщательное тестирование и отладка.
- TR-3: Злоумышленники могут взломать нашу систему и украсть конфиденциальные данные (см. раздел "ADR-2 Security").
Задача
Необходимо определить архитектурный стиль, который наибольшим образом подходит для решения задач исходя из определенных целей, функциональных и нефункциональных требований на фазе “MVP”.
Обоснование
Модульный монолит и микросервисная архитектура оба имеют свои достоинства и недостатки, и выбор между ними зависит от выявленных нами ранее ключевых архитектурных характеристик. Вот некоторые преимущества модульного монолита по сравнению с микросервисной архитектурой:
- Простота разработки и развертывания: В модульном монолите весь код находится в одном приложении, что облегчает разработку и развертывание. Нет необходимости управлять множеством сервисов и их зависимостями.
- Производительность: Запросы внутри монолита обычно обрабатываются быстрее, чем в микросервисной архитектуре, где есть накладные расходы на межсервисное взаимодействие.
- Простота масштабирования: Масштабирование монолита может быть проще, чем масштабирование микросервисной архитектуры, поскольку требуется масштабировать только одно приложение. Однако масштабирование возможно только горизонтальное и есть определенный порог, после которого стоимость железа становится слишком высокой.
- Проще управление: Управление одним приложением проще, чем управление множеством микросервисов. Нет необходимости отслеживать версии и зависимости между микросервисами.
- Легкость в тестировании: Тестирование монолита может быть более простым, чем тестирование микросервисов, поскольку нет необходимости в тестировании межсервисного взаимодействия.
Однако стоит помнить, что преимущества модульного монолита могут стать недостатками в случае больших и сложных проектов. С ростом размера и сложности приложения модульный монолит может стать труднее поддерживать и масштабировать. Микросервисная архитектура часто предпочтительнее для больших и распределенных систем, где требуется высокая гибкость, масштабируемость и независимость компонентов.
Мы принимаем указанные выше риски, поскольку на текущем этапе система не должна обрабатывать большое количество заказов, команда разработки также составляет не более 10 человек.
Решение
Оба варианта архитектуры имеют свои преимущества и недостатки, но характеристики архитектуры Modular Monolith на данном этапе проекта подходят больше.
Кроме собственных предположений, мы можем обратиться к шаблону от Mark Richards.
https://www.developertoarchitect.com/downloads/worksheets.html
Контекст
Необходимо определить архитектурный стиль, который наибольшим образом подходит для решения задач исходя из определенных целей, функциональных и нефункциональных требований на фазе “MVP”.
В разделе Key Architectural Characteristics перечислены такие характеристики, как agility, scalability и modularity.
Обоснование
Микросервисная архитектура имеет несколько преимуществ по сравнению с модульным монолитом. Вот некоторые из них:
- **Гибкость и масштабируемость: **Микросервисы могут быть независимо масштабируемы в зависимости от потребностей. Это позволяет эффективнее использовать ресурсы и масштабировать отдельные компоненты приложения в зависимости от нагрузки.
- Легкость в развертывании и обновлении: Микросервисы могут быть независимо развернуты и обновлены без необходимости внесения изменений в другие компоненты системы. Это упрощает процесс разработки, развертывания и обновления приложения.
- Модульность: Микросервисы могут соответствовать граничным контекстам, что позволяет изолировать и управлять сложными областями бизнеса. Различные команды разработки могут работать над отдельными микросервисами, используя разный технологический стек, различные подходы и организационную структуру.
- **Технологическая гетерогенность: **В микросервисной архитектуре каждый сервис может быть разработан и реализован с использованием различных технологий и языков программирования в зависимости от его потребностей. Это позволяет выбирать наиболее подходящие технологии для решения конкретных задач.
- Отказоустойчивость и изоляция ошибок: Если один из микросервисов выходит из строя или становится недоступным, остальные сервисы могут продолжать работу без проблем. Это обеспечивает более высокую отказоустойчивость и изоляцию ошибок в системе.
- **Более быстрая разработка и меньшие затраты на масштабирование: **Микросервисы обычно могут быть разработаны быстрее благодаря их небольшому размеру и изолированности функциональности. Это также позволяет быстрее вносить изменения и адаптироваться к новым требованиям.
- **Улучшенная поддержка непрерывной поставки и развертывания: **Микросервисная архитектура поддерживает принципы непрерывной поставки и развертывания, позволяя чаще выпускать обновления и изменения в продукт.
- **Более эффективное использование ресурсов: **Микросервисы позволяют выделить ресурсы в соответствии с конкретными потребностями каждого сервиса, что обеспечивает более эффективное использование ресурсов.
Стоит помнить, что переход на микросервисную архитектуру имеет и свои недостатки, например усложняется отладка системы, требуется больше внимания уделять версионированию микросервисов и API, увеличивается стоимость поддержки в целом.
Решение
Характеристики микросервисной архитектуры на данном этапе проекта подходят больше.
Кроме собственных предположений, мы можем обратиться к шаблону от Mark Richards.
https://www.developertoarchitect.com/downloads/worksheets.html
Контекст
Самая важная и желанная функциональность, которую должна предоставить платформа - это возможность поиска по меню, кухням, ресторанам и прочему. В процессе заказа еды эта функциональность станет отправной точкой для всех клиентов, если только у них еще нет любимого ресторана, из которого они могут выбрать блюда. Таким образом, необходимо обеспечить персонализированный опыт открытия и поиска, основанный на истории поиска и заказов клиента в прошлом. Как видно, эта часть всей системы будет требовать много времени для чтения.
Нам нужна служба поиска ресторана в Restaurant Service, которая выполняет запросы на основе пользовательских данных и возвращает результат для отображения в пользовательском интерфейсе.
Решение
Мы можем подумать об использовании популярных готовых поисковых предложений на рынке, таких как Elasticsearch или Apache Solr, для быстрого поиска в соответствии с параметрами поиска пользователя. Обе эти технологии с открытым исходным кодом, распределенные, основаны на Apache Lucene и имеют свои сильные и слабые стороны.
В Elasticsearch есть возможность выполнять запрос Geo-distance, который можно использовать для возврата всех ресторанов/меню, которые ищет пользователь, на основе определенного радиуса от местоположения пользователя. По сути, это означает, что пользователям будут показаны только те рестораны, которые находятся в шаговой доступности от адреса пользователя. Аналогично, Apache Solr также имеет функцию Spatial Search, которая предназначена для географического поиска. Таким образом, Elasticsearch очень быстро выдает результаты и может быть запрошен напрямую. Чтобы еще больше сократить время ожидания и улучшить работу пользователей, нам следует использовать кэш, работающий вместе со Restaurant Service.
Контекст
Требуется проработать дизайн сервиса заказов.
Решение
Этот сервис будет управлять выбором меню, корзиной и размещением заказов на еду. Он будет обрабатывать платежи с помощью Payment Gateway и сохранять результат в базе данных Orders. Поскольку размещение заказов носит транзакционный характер, лучше всего использовать реляционную базу данных.
Клиенты смогут получить полную квитанцию об оплате заказа с помощью этого сервиса, а также другие подробности о заказе. Они также могут отменить заказ, если по какой-то причине передумали. Клиенты также могут просмотреть историю своих прошлых заказов.
Контекст
Требуется проработать дизайн шлюза для интеграции с сервисами оплаты
Решение
Этот компонент обеспечит взаимодействие с такими популярными платежными шлюзами, как Kaspi Pay, PayPal, ApplePay, Google Pay или с отдельными поставщиками кредитных карт, такими какVisa, Mastercard и т. д. Order Service будет взаимодействовать с этим компонентом, чтобы обеспечить оплату в момент подтверждения заказа. Взаимодействие должно быть синхронным.
Контекст
Требуется проработать дизайн шлюза для интеграции с сервисами рассылки SMS, Push и писем.
Решение
Этот сервис отвечает за доставку уведомлений каждому клиенту платформы. Уведомления могут рассылаться отдельным клиентам в соответствии с их предпочтениями, которые они установили для их получения. Некоторые участники могут предпочесть push-уведомления, другие - текстовые или электронные письма. Этот сервис должен абстрагироваться от среды, на которой отправляются уведомления. Это означает, что базовые взаимодействия с оператором мобильной связи, поставщиками услуг электронной почты и т. д. будут абстрагированы. Действующие лица также могут получать уведомления In-App. В обязанности сервиса входит уведомление:
- Клиента: о различных этапах выполнения заказа, например, о том, что заказ был успешно оформлен, или о том, что ресторан принял заказ, или о том, что грузчик забрал заказ и едет его доставлять.
- Ресторан: что заказ был размещен, или исполнитель назначен на заказ, или исполнитель находится в пути, чтобы забрать заказ.
- Курьер: что заказ ожидает своей очереди на принятие, или что заказ готов к приему, или что принятый им заказ задерживается и т. д.
Контекст
Необходимо определить различные точки отказа в системе и постараться иметь реплики/резервные копии для каждой из них на случай гибели какого-либо компонента
Решение
Каждый микросервис должен быть горизонтально масштабируемым. Инфраструктура NoSQL баз данных также должна иметь несколько узлов. Система поиска должна иметь несколько узлов. Очереди также должна иметь разделы и репликацию. При необходимости каждый сервис/компонент можно масштабировать по отдельности. Можно включить автомасштабирование, чтобы справиться с нагрузкой на отдельные сервисы, например, запустить больше экземпляров в случае высокой пиковой нагрузки. Кроме того, в случае выхода из строя одного из узлов или любого раздела в инфраструктуре очередей другой экземпляр может взять на себя эту работу. После этого вышедший из строя узел может произвести очистку и перезапуститься, используя процесс, называемый самовосстановлением.
Контекст
Требуется повысить отзывчивость клиентских сервисов.
Решение
Данные, основанные на последних заказах в районе, или наиболее часто заказываемых блюдах, или искомых объектах, могут кэшироваться, чтобы Restaurant Service мог отдавать такую информацию из кэша, а не СУБД, и немедленно возвращать несколько рекомендаций. Изображения ресторанов и блюд также можно кэшировать, вместо того чтобы постоянно обращаться к объектному хранилищу. В кэше будут храниться популярные или наиболее часто заказываемые пункты меню/рестораны в конкретном районе, и экран поиска должен показывать эти варианты по умолчанию. Использование кэша определенно ускоряет просмотр результатов поиска.
Одними из популярных технологий кэширования, доступных на рынке, являются Redis, и Memcached. Стратегией вытеснения кэша в нашем случае может быть алгоритм наименее часто используемого (LRU) или наименее часто используемого (LFU), либо их комбинация.
The numbers vary depending on the language and implementation.
- char: 1B (8 bits)
- char (Unicode): 2B (16 bits)
- short: 2B (16 bits)
- Int: 4B (32 bits)
- double: 4B (32 bits)
- long: 8B (64 bits)
- UUID/GUID: 16B
Objects
- File: 100 KB
- Web Page: 100 KB (not including images)
- Picture: 200 KB
- Short Posted Video: 2MB
- Steaming Video: 50MB per minute
- Long/Lat: 8B
Cost of Operations
- Read sequentially from HDD: 30 MB/s
- Read sequentially from SSD: 1 GB/s
- Read sequentially from memory: 4 GB/s
- Read sequentially from 1Gbps Ethernet: 100MB/s
- Cross continental network: 6–7 world-wide round trips per second
S3 Storage
- Storage: 20TB
- Connections: 30K
- Requests: 25K per second
SQL Databases
- Storage: 60TB
- Connections: 30K
- Requests: 25K per second
Cache
- Storage: 300 GB
- Connections: 10k
- Requests: 100k per second
Web Servers
- Requests: 5–10k requests per second
Queues/Streams
- Requests: 1000–3000 requests/s
- Throughput: 1MB-50MB/s (Write) / 2MB-100MB/s (Read)