Нужны идеи и ответы/советы по проектированию и архитектуре системы на стороне тяжелого клиента.

Я надеюсь, что это нормально, чтобы опубликовать это здесь. Мне было интересно, может ли кто-нибудь поделиться примерными вопросами/идеями интервью по дизайну и архитектуре системы, особенно с упором на клиентскую сторону/сеть и некоторым участием сервера. (как палач с сервером, который просто хранит высокие баллы и предоставляет текущее угадываемое слово) У меня приближается собеседование, и, поскольку это полный набор инженеров-программистов, 3, 45 минут каждый, вопрос о дизайне системы и архитектуре будет задан для разработки приложения с тяжелым клиентским компонентом, а также для изучения отношений клиент/сервер.

Кроме того, любая информация, которой вы можете поделиться о том, как подойти к этому / как это должно выглядеть на белой доске, было бы здорово. Мне удобно рисовать более интенсивный дизайн сервера, но я немного смущен тем, как рисовать архитектуру/систему на стороне клиента.

СПАСИБО!


person BYC    schedule 07.09.2016    source источник


Ответы (1)


Было несколько очень интересных вопросов, которые мне задали, и обсуждение продолжалось более часа :)

  1. Разработайте программное обеспечение для редактирования музыки, но загвоздка в том, что несколько человек будут работать над одной и той же песней/треком одновременно. Он также должен поддерживать автономное редактирование и автоматическое обнаружение и разрешение коллизий (в то время я мало знал об операционной трансформации, используемой в Google Docs, но мне действительно было весело решать ее).

  2. Как вы проектируете систему совместного использования автомобилей? (Как вы можете догадаться, этот вопрос был задан в интервью известной компании, занимающейся райдшерингом)

Я не хочу подробно излагать здесь дизайнерские идеи, но что помогло мне решить такие проблемы, так это то, что я знал, что идеального ответа не существует, и вы имеете дело с множеством неясностей. Вы должны действовать поэтапно, детализируя требования и пытаясь решить их архитектурно, используя общие шаблоны, такие как кэширование, горизонтальное масштабирование и т. д. Большинство компаний даже ищут такие черты, как отказ от преждевременной оптимизации за счет слишком большого количества обобщений и т. д.

person Ramkumar Venkataraman    schedule 09.09.2016
comment
совместное использование автомобилей, вероятно, будет тяжелым для сервера, а клиент будет простым окном для логики принятия решения о группировании пула сервера. - person BYC; 10.09.2016
comment
Не совсем так, вам нужно отслеживать, где находятся машины, может ли водитель вместить больше людей и т. д. Если вы читали архитектуру Uber, они используют телефон водителя в качестве своего рода резервного центра обработки данных, когда основной ЦОД выходит из строя или есть отказоустойчивость. Это проблема спроса-предложения, и обе стороны уравнения одинаково сложны (хотя я согласен, что большая часть фактической работы по планированию выполняется на стороне сервера). - person Ramkumar Venkataraman; 10.09.2016