Зачем нужна секция «дизайн систем»?

Некоторые считают, что нужно начитать всяких базвордов и уметь расставить их в нужные места на диаграмме.

На самом деле, суть в том, чтобы отличить человека, который строит «сферических коней в вакууме», от человека, который запускал эти самые системы в продакшен. То есть понимает как его код будет бежать на реальных машинах, собирал метрики, сталкивался с проблемами масштабирования.

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

Грубо говоря, насколько прагматично человек подходит к дизайну систем, через призму той боли, которую он уже пережил.

Соответсвенно, научиться этому можно только если уже строил такие системы, и набил шишки. Поэтому систем-дизайн нужен чтобы оценить «синьорность». Алгосики — минимум, который все должны сдать, а дальше можно дать оценку только через вот такой разговор на «свободную тему», где правильных ответов нет.

То есть в дизайне всегда есть трейдофы, ограничения. Условно хотим построить систему бронирования отелей, а как данные получать? Будем скрейпить сайт Хилтона пока нас не заблокируют навсегда? Ну нет. Должны быть АПИ. А эти АПИ точно всегда актуальные данные возвращают? Ну нет, мы ж не будем каждую секунду их запрашивать — есть какие-то TPS. Нужен кэш, а что будем делать когда случится рассинхрон, то есть человек комнату забронировал, а на самом деле ее уже нет?

Другая классическая ошибка: отелей много, MySQL не подойдёт. А почему? А сколько всего отеле в мире? Ну не так уж и много, на самом деле! Кроме того, это отели, а значит можно хорошо шардировать (географически, например) то есть разложить их в разные базы и роутить куда надо запросы за данными.


И так далее, с интервьюером продолжаешь раскапывать задачу до дна.