tgoop.com/coding_interviews/175
Last Update:
Зачем нужна секция «дизайн систем»?
Некоторые считают, что нужно начитать всяких базвордов и уметь расставить их в нужные места на диаграмме.
На самом деле, суть в том, чтобы отличить человека, который строит «сферических коней в вакууме», от человека, который запускал эти самые системы в продакшен. То есть понимает как его код будет бежать на реальных машинах, собирал метрики, сталкивался с проблемами масштабирования.
Чтобы не было такого, что сеть у нас всегда 100% надежная, latency не существует, а все зависимости (на самом деле написанные на коленке) работают как часы.
Грубо говоря, насколько прагматично человек подходит к дизайну систем, через призму той боли, которую он уже пережил.
Соответсвенно, научиться этому можно только если уже строил такие системы, и набил шишки. Поэтому систем-дизайн нужен чтобы оценить «синьорность». Алгосики — минимум, который все должны сдать, а дальше можно дать оценку только через вот такой разговор на «свободную тему», где правильных ответов нет.
То есть в дизайне всегда есть трейдофы, ограничения. Условно хотим построить систему бронирования отелей, а как данные получать? Будем скрейпить сайт Хилтона пока нас не заблокируют навсегда? Ну нет. Должны быть АПИ. А эти АПИ точно всегда актуальные данные возвращают? Ну нет, мы ж не будем каждую секунду их запрашивать — есть какие-то TPS. Нужен кэш, а что будем делать когда случится рассинхрон, то есть человек комнату забронировал, а на самом деле ее уже нет?
Другая классическая ошибка: отелей много, MySQL не подойдёт. А почему? А сколько всего отеле в мире? Ну не так уж и много, на самом деле! Кроме того, это отели, а значит можно хорошо шардировать (географически, например) то есть разложить их в разные базы и роутить куда надо запросы за данными.
И так далее, с интервьюером продолжаешь раскапывать задачу до дна.
BY 💻 Coding interviews in a nutshell
Share with your friend now:
tgoop.com/coding_interviews/175