asisakov

SYSTEM DESIGN
Часть 2

Начало выше ⬆️

3. Построение первоначальной архитектуры

После подготовленных требований мы уже можем примерно накидать базовый шаблон нашей системы. Обычно это рисуется в виде схемы и выглядит следующим образом. Например, в нашем случае важно, чтобы юзер взаимодействовал с нами через Load balancer, чтобы мы могли выдержать всю нагрузку. Далее мы получаем от него его местоположение и запрос для поиска ближайшего магазина. Допустим, отправляем локацию юзера по API в блок с алгоритмом, реализующим нахождение ближайшего магазина (который идет в свою базу с магазинами, где координаты хранятся через сервис, поддерживающий QuadTrees) - получаем координаты магазина. Далее отправляем координаты юзера и магазина в блок с вычислением времени маршрута (который сначала из базы строит маршрут на графах допустим при помощи алгоритма Дейкстры, идет в сторонний сервис с анализом загруженности и затем только выдает результат в виде времени) - любые детали наших блоков надо уметь пояснить. Результат с обоих блоков отправляем юзеру. Дополнительно конечно же надо реализовать подгрузку отзывов, но это вы наверно уже сами догадаетесь как сделать.

4. А какие должны быть базы и сколько для них требуется памяти?

Дальше надо прикинуть, какую информацию нам надо хранить в наших табличках для обеспечения заявленной функциональности. Прикидываем, что нам необходимо всегда держать в быстром доступе - это id магазина и его координаты. Также в отдельной табличке хранить id магазина, отзыв и дату его формирования. По каждому столбцу надо понять занимаемую память и в целом можно прикинуть капаситет, необходимый для хранения N магазинов (это тоже заранее обговаривается в условиях) и N*k отзывов. Для полученной цифры можем оценить, влезет ли это в кэш. Если влезает, то хорошо, если не влезает, то думаем как сделать так, чтобы все было доступно и при этом к этому был быстрый доступ (важно в случае с медиаконтентом например). При этом надо аргументированно выбрать тип базы данных (допустим relational database, потому что все храним в виде ключа и значения) и платформу (пусть будет Postgres). Плюсом желательно добавить, где тут появляется Location-Based Service.

5. Погружение глубже

После основных моментов можно погружаться в глубокое исследование блоков, либо усовершенствование архитектуры - например, чтобы выдержать пиковые нагрузки. Также можно поговорить поглубже про базы данных - репликации, партицирование, шардирование. Можно поговорить про мониторинг и брокер сообщений (например Kafka / RabbitMQ + Grafana), можно упомянуть различные способы балансировки нагрузки - round robin, least connections, SDN adaptive. Короче, погружаться в любую часть и насколько хочется. Скорее всего интервьюер будет задавать наводящие вопросы с какими-либо корнер кейсами. Возможно даже нужно будет обсудить, как вы все это будете выкатывать в прод.

В данном собеседовании в принципе нет какого-то единого правильного решения. Все строится с учетом получаемых достоинств и недостатков всей системы с целью обеспечить необходимую функциональность. Например, одна из сложных тем, это банковские транзакции, где нам на 100% надо обеспечить consistency. Возвращаясь к вопросу про заботать это в теории мы понимаем, что без практики это будет совсем тяжело. Поэтому моя рекомендация здесь не только изучать, а делать что-то руками на работе или в личных проектах.

Кстати, в этом собеседовании важно проявить не только свою экспертность, но и умение формализовать задачу, объяснить простым языком, нарисовать понятную схему, продемонстрировать и глубину погружения в компоненты, и широту понимания разных типов систем. С моментом изучения систем в ширину я бы порекомендовал почитать канал Жени Мунина ML Advertising - там он пишет про data science и часто разбирает различные системы на предмет систем дизайна. Например тут есть рассказ про Kafka, тут можно прочитать про проектирование Google Doc, а про дизайн Убера можно почитать вот тут. А в этом посте например рассматриваются популярные архитектурные стили.

Продолжение ниже ⬇️

#systemdesign #interview #collaboration

Telegram

ML Advertising

Пишу про AdTech, AI и разработку

Для связи: @evgenii_munin

🔥6❤3👍2

www.tgoop.com/asisakov_channel/236

348 viewsedited  Mar 31, 2024 at 17:23

SYSTEM DESIGN
Часть 2

Начало выше ⬆️

3. Построение первоначальной архитектуры

После подготовленных требований мы уже можем примерно накидать базовый шаблон нашей системы. Обычно это рисуется в виде схемы и выглядит следующим образом. Например, в нашем случае важно, чтобы юзер взаимодействовал с нами через Load balancer, чтобы мы могли выдержать всю нагрузку. Далее мы получаем от него его местоположение и запрос для поиска ближайшего магазина. Допустим, отправляем локацию юзера по API в блок с алгоритмом, реализующим нахождение ближайшего магазина (который идет в свою базу с магазинами, где координаты хранятся через сервис, поддерживающий QuadTrees) - получаем координаты магазина. Далее отправляем координаты юзера и магазина в блок с вычислением времени маршрута (который сначала из базы строит маршрут на графах допустим при помощи алгоритма Дейкстры, идет в сторонний сервис с анализом загруженности и затем только выдает результат в виде времени) - любые детали наших блоков надо уметь пояснить. Результат с обоих блоков отправляем юзеру. Дополнительно конечно же надо реализовать подгрузку отзывов, но это вы наверно уже сами догадаетесь как сделать.

4. А какие должны быть базы и сколько для них требуется памяти?

Дальше надо прикинуть, какую информацию нам надо хранить в наших табличках для обеспечения заявленной функциональности. Прикидываем, что нам необходимо всегда держать в быстром доступе - это id магазина и его координаты. Также в отдельной табличке хранить id магазина, отзыв и дату его формирования. По каждому столбцу надо понять занимаемую память и в целом можно прикинуть капаситет, необходимый для хранения N магазинов (это тоже заранее обговаривается в условиях) и N*k отзывов. Для полученной цифры можем оценить, влезет ли это в кэш. Если влезает, то хорошо, если не влезает, то думаем как сделать так, чтобы все было доступно и при этом к этому был быстрый доступ (важно в случае с медиаконтентом например). При этом надо аргументированно выбрать тип базы данных (допустим relational database, потому что все храним в виде ключа и значения) и платформу (пусть будет Postgres). Плюсом желательно добавить, где тут появляется Location-Based Service.

5. Погружение глубже

После основных моментов можно погружаться в глубокое исследование блоков, либо усовершенствование архитектуры - например, чтобы выдержать пиковые нагрузки. Также можно поговорить поглубже про базы данных - репликации, партицирование, шардирование. Можно поговорить про мониторинг и брокер сообщений (например Kafka / RabbitMQ + Grafana), можно упомянуть различные способы балансировки нагрузки - round robin, least connections, SDN adaptive. Короче, погружаться в любую часть и насколько хочется. Скорее всего интервьюер будет задавать наводящие вопросы с какими-либо корнер кейсами. Возможно даже нужно будет обсудить, как вы все это будете выкатывать в прод.

В данном собеседовании в принципе нет какого-то единого правильного решения. Все строится с учетом получаемых достоинств и недостатков всей системы с целью обеспечить необходимую функциональность. Например, одна из сложных тем, это банковские транзакции, где нам на 100% надо обеспечить consistency. Возвращаясь к вопросу про заботать это в теории мы понимаем, что без практики это будет совсем тяжело. Поэтому моя рекомендация здесь не только изучать, а делать что-то руками на работе или в личных проектах.

Кстати, в этом собеседовании важно проявить не только свою экспертность, но и умение формализовать задачу, объяснить простым языком, нарисовать понятную схему, продемонстрировать и глубину погружения в компоненты, и широту понимания разных типов систем. С моментом изучения систем в ширину я бы порекомендовал почитать канал Жени Мунина ML Advertising - там он пишет про data science и часто разбирает различные системы на предмет систем дизайна. Например тут есть рассказ про Kafka, тут можно прочитать про проектирование Google Doc, а про дизайн Убера можно почитать вот тут. А в этом посте например рассматриваются популярные архитектурные стили.

Продолжение ниже ⬇️

#systemdesign #interview #collaboration

BY asisakov