Как успешно пройти System Design Interview? [Часть 2]
4️⃣ Model
Какие основные сущности есть в нашей системе?
Например, для Uber это могут быть:
• Пассажир
• Водитель
• Поездка
• Локация
Какие данные мы храним? Какие связи между ними? Что будем читать, а что писать?
На этом мы не обсуждаем, какую базу данных мы собираемся использовать, на этом этапе мы разбираемся, какие сущности будут фигурировать в системе.
5️⃣ API
Теперь стоит понять, как клиенты будут взаимодействовать с нашей системой.
Например:
POST /rides
Headers:
• JWT
Request Body:
• pickupLocation
• dropoffLocation
Response Body:
• rideId
• status
• estimatedPrice
• estimatedArrivalTime
Это не обязательно должен быть REST API, но так проще всего объяснить, какие методы будут использоваться.
Главная задача - показать основные взаимодействия между клиентом и системой и понять, какие данные проходят через эти запросы.
6️⃣ High-level design
На этом этапе наконец-то можно продемонстрировать навыки рисования, но помни, что каждый добавленный блок не бесплатный для бизнеса, и тебе нужно будет каждый из них пояснить.
Не всегда хорошая практика добавлять что-то, потому что ты использовал это на прошлых проектах, и по этой причине добавлять, например, Kafka, когда может быть достаточно чего-то попроще или вообще синхронного вызова. Если ты видишь, что без Kafka / Streaming Platform / Queue не обойтись, то при добавлении этого блока нужно объяснить причины и потенциальные проблемы.
По моему мнению, в хорошем дизайне систем важны не технологии сами по себе (лучше сказать Streaming Platform / Queue, чем Kafka / Rabbit MQ), а набор концепций с объяснением, почему ты принимаешь именно такое решение.
Главное, не делай слишком сложный дизайн сейчас, сделай быстрые наброски основного флоу. Остальное - в следующей секции.
Что же использовать для рисования диаграммы? Компания либо предоставит свою рисовалку, как, например, делает Google, либо разрешит использовать свою, например Excalidraw, Miro и тому подобное.
Также некоторые люди используют Apple Pencil ✍️ и их аналоги, но будь аккуратен с почерком: всё должно быть понятно. Плюс, если ты используешь блоки в Excalidraw или Miro, то дизайн легко переделать/доделать вместо того, чтобы стирать его и рисовать заново.
На этом этапе все базовые требования должны быть закрыты.
7️⃣ Deep Dives
Теперь у нас есть базовый дизайн, и можно начать разбирать его глубже.
На этом этапе нужно проверить, действительно ли система удовлетворяет нашим «нефункциональным требованиям», найти потенциальные "узкие горлышки" системы и понять, что будет происходить при росте нагрузки.
Например, если мы проектируем Uber 🚘, то один из интересных вопросов - как быстро находить ближайших водителей.
Можно начать обсуждать:
• Как хранить и постоянно обновлять локацию миллионов водителей?
• Как эффективно искать водителей поблизости?
• Что произойдет, если тысячи пользователей одновременно запросят машину в одном районе?
• Что делать, если водитель принял поездку, но её успели предложить другому пользователю?
• Бывает ли вообще так, что поездка может быть предложена нескольким водителям?
Здесь уже можно глубже разобрать Geospatial Indexing, Partitioning, Cache, Consistency, и закапываться в детали можно и нужно до бесконечности, пока не кончится время собеседования.
Также стоит возвращаться к требованиям и проверять, все ли пункты покрыты. Если мы обещали низкую latency при поиске машины, то нужно показать, за счёт чего наш дизайн действительно сможет её обеспечить.
Чем выше твой уровень, тем меньше стоит ждать, пока интервьюер сам найдёт проблему. На Senior / Staff необходимо самому посмотреть на дизайн, найти потенциальное "узкое горлышко" и предложить его разобрать.
Помни: ты должен лидить собеседование и решать неопределённости.
4️⃣ Model
Какие основные сущности есть в нашей системе?
Например, для Uber это могут быть:
• Пассажир
• Водитель
• Поездка
• Локация
Какие данные мы храним? Какие связи между ними? Что будем читать, а что писать?
На этом мы не обсуждаем, какую базу данных мы собираемся использовать, на этом этапе мы разбираемся, какие сущности будут фигурировать в системе.
5️⃣ API
Теперь стоит понять, как клиенты будут взаимодействовать с нашей системой.
Например:
POST /rides
Headers:
• JWT
Request Body:
• pickupLocation
• dropoffLocation
Response Body:
• rideId
• status
• estimatedPrice
• estimatedArrivalTime
Это не обязательно должен быть REST API, но так проще всего объяснить, какие методы будут использоваться.
Главная задача - показать основные взаимодействия между клиентом и системой и понять, какие данные проходят через эти запросы.
6️⃣ High-level design
На этом этапе наконец-то можно продемонстрировать навыки рисования, но помни, что каждый добавленный блок не бесплатный для бизнеса, и тебе нужно будет каждый из них пояснить.
Не всегда хорошая практика добавлять что-то, потому что ты использовал это на прошлых проектах, и по этой причине добавлять, например, Kafka, когда может быть достаточно чего-то попроще или вообще синхронного вызова. Если ты видишь, что без Kafka / Streaming Platform / Queue не обойтись, то при добавлении этого блока нужно объяснить причины и потенциальные проблемы.
По моему мнению, в хорошем дизайне систем важны не технологии сами по себе (лучше сказать Streaming Platform / Queue, чем Kafka / Rabbit MQ), а набор концепций с объяснением, почему ты принимаешь именно такое решение.
Главное, не делай слишком сложный дизайн сейчас, сделай быстрые наброски основного флоу. Остальное - в следующей секции.
Что же использовать для рисования диаграммы? Компания либо предоставит свою рисовалку, как, например, делает Google, либо разрешит использовать свою, например Excalidraw, Miro и тому подобное.
Также некоторые люди используют Apple Pencil ✍️ и их аналоги, но будь аккуратен с почерком: всё должно быть понятно. Плюс, если ты используешь блоки в Excalidraw или Miro, то дизайн легко переделать/доделать вместо того, чтобы стирать его и рисовать заново.
На этом этапе все базовые требования должны быть закрыты.
7️⃣ Deep Dives
Теперь у нас есть базовый дизайн, и можно начать разбирать его глубже.
На этом этапе нужно проверить, действительно ли система удовлетворяет нашим «нефункциональным требованиям», найти потенциальные "узкие горлышки" системы и понять, что будет происходить при росте нагрузки.
Например, если мы проектируем Uber 🚘, то один из интересных вопросов - как быстро находить ближайших водителей.
Можно начать обсуждать:
• Как хранить и постоянно обновлять локацию миллионов водителей?
• Как эффективно искать водителей поблизости?
• Что произойдет, если тысячи пользователей одновременно запросят машину в одном районе?
• Что делать, если водитель принял поездку, но её успели предложить другому пользователю?
• Бывает ли вообще так, что поездка может быть предложена нескольким водителям?
Здесь уже можно глубже разобрать Geospatial Indexing, Partitioning, Cache, Consistency, и закапываться в детали можно и нужно до бесконечности, пока не кончится время собеседования.
Также стоит возвращаться к требованиям и проверять, все ли пункты покрыты. Если мы обещали низкую latency при поиске машины, то нужно показать, за счёт чего наш дизайн действительно сможет её обеспечить.
Чем выше твой уровень, тем меньше стоит ждать, пока интервьюер сам найдёт проблему. На Senior / Staff необходимо самому посмотреть на дизайн, найти потенциальное "узкое горлышко" и предложить его разобрать.
Помни: ты должен лидить собеседование и решать неопределённости.