Дизайн высокого уровня UberEats

Question

Я готовлюсь к собеседованию по дизайну высокого уровня для SDE 3-4.

Я разработал этот дизайн для UberEats, и у меня возникли вопросы.

Функциональные требования:

1. Получить список ближайших ресторанов
2. Блюда из ресторана
3. В зависимости от местоположения пользователя мы должны рассчитать ближайшие рестораны
4. Получение заказа и обработка его в рестораны
5. Оплата может быть произведена третьим лицом
6. Расположение и режим работы ресторана
7. Отслеживание статуса заказа / Уведомления пользователям
8. Система рекомендаций
9. Интеграция с рестораном OMS
10. Доставка
11. Отзывы пользователей о ресторане

И нефункциональные:

1. Низкая задержка
2. Высокая доступность
3. Высокая консистенция
4. 1 миллион заказов в день
5. 500 тысяч DAU

Ниже я разместил фото своего дизайна.

Мои вопросы:

Я должен указать, какой тип связи между микросервисами?

Это хороший уровень детализации или мне нужно углубиться?

Часть службы уведомлений, я не знаю, правильно ли я думал о messageQueue, и OMS (система управления заказами) позаботится о размещении обновлений заказа в очереди сообщений.

Я провел небольшое исследование, но я очень запутался в этом типе дизайна, поэтому вся помощь приветствуется.

Дизайн высокого уровня UberEats

Answer 1

Я не знаком с методом Amazon и конкретными ожиданиями, которые они могут иметь в отношении того, что вам нужно предоставить. Но я могу поговорить в более общем плане о HLD и двух ваших конкретных вопросах.

Общие комментарии к вашей диаграмме и HLD

1. Мне нравится выбранный вами подход «архитектура на странице», в котором вы передаете много связанной информации вместе, а не утопляете читателей в 1000-страничном документе. Одна вещь, которую вы можете улучшить, - это презентация / макет, чтобы информация была должным образом разделена на части. Так будет легче перевариваться. Заголовки, выделенные жирным шрифтом, разделительные линии или закрывающие прямоугольники / затененные фоновые панели и т. Д.
2. Всегда думайте об аудитории - что им нужно знать? И ваше сообщение - что вы хотите донести. Подумайте об этом, это поможет вам настроить как информацию, которую вы включаете, так и то, как вы ее представляете.
3. Демонстрирует ли ДВУ ответы на задаваемые вопросы? Например, нефункциональные: глядя на свой ДВУ, откуда вы знаете, что он будет «высокодоступным» и 1 млн заказов в день - знаете ли вы, сколько это в среднем в час, минуту? ... и что выбранные компоненты / технологии могут справиться с этим в этой конструкции?
4. Схема данных выглядит нормально для HLD, но может оказаться полезным добавление взаимосвязей (соединительных линий). Если он становится слишком сложным (слишком много соединений), может оказаться невозможным включить его на ту же страницу, что и все остальное.
5. У вас может быть один пробел - это (API) "Ресурсы" (подробнее о них здесь). API, особенно на основе REST, должны иметь дело с ресурсами. Вы вызвали схему данных (как данные хранятся). Ресурсная модель не должна быть сложной. Но, как я уже сказал, вам может и не понадобиться. Если бы я делал HLD, включающий API, я бы, вероятно, сделал это, особенно если API собирался использовать сторонними внешними сторонами.

>> (Должен) я должен указать, какой тип связи между микросервисами?

Обратитесь к моему №2 выше. Краткий ответ, вероятно, утвердительный, с точки зрения ДВУ в целом, но не обязательно в контексте одной диаграммы.

Если у вас много микросервисов, и особенно если отношения между ними нетривиальны, то у вас может быть две диаграммы: одна показывает все микросервисы и их взаимосвязь, а вторая показывает различные типы связи. Обычно связь между микросервисами должна быть относительно согласованной, поэтому вы должны иметь возможность делать это, имея дело с обменом данными между типами микросервисов, а также любыми особыми случаями, если они существуют.

Вторая «диаграмма» также может быть таблицей / матрицей, в которой перечислены микросервисы и ключевая информация о них, например: внешний вид y / n, тип (служба, оркестровка и т. Д.), В какой бизнес-области он находится и т. Д.

>> Это хороший уровень детализации или мне нужно углубиться?

1. Я не могу говорить об ожиданиях Amazon, но в целом уровень детализации хороший - вы, вероятно, не захотите углубляться.
2. Ваша основная диаграмма выполняет две функции: некоторые элементы описываются функционально (например, «Rider App»), некоторые - чисто техническими (например, «Очередь обмена сообщениями»), большинство - обоими. Я предпочитаю второе, просто постарайтесь быть максимально последовательным. Если бы я делал это, у меня могло бы быть функциональное представление и отдельное техническое представление, потому что за пределами определенного уровня сложности это может быть слишком сложно.
3. посмотрите, сможете ли вы сделать диаграмму более изящной; это может показаться забавным, но диаграмму, которая элегантна и хорошо выглядит, будет легче понять - только если вы ставите эстетику настолько выше смысла, что смысл теряется. Простая вещь здесь - попытаться расположить элементы так, чтобы их макет имел смысл (например, по уровням или уровням) - и поэтому у вас будет меньше пересекающихся соединителей ... когда много пересекающихся соединителей выглядит беспорядочно, и люди часто переводят беспорядочно = сложный.
4. Не бойтесь использовать немного цвета, если это поможет внести ясность.