#машины_разное В продолжение https://t.me/manandthemachine/6 | Человек и машина

#машины_разное

В продолжение https://t.me/manandthemachine/650

Олег очень правильное замечание сделал. Есть "классический" system design, а есть NALSD - Non-Abstract Large System Design.

Иными словами, эскалаторы в ТЦ - это NALSD. Запили мне Инстаграм - это SD.

NALSD очень любят FAANG, потому что к FAANG'у ваши знания кубов и авсов неприменимы - у них свои системы, и учиться работать с ними придется по новой. Там от вас просят набросать некий дизайн, а потом наскоро посчитать сколько и какого размера узлов надо, чтобы обработать входящий трафик с объемом 3.57 Гбит/с.

В обычном дизайне подход более прагматичный и приближенный к обыденности. Он, повторюсь, ожидает от вас reverse bullshit bingo ("назови так много ключевых слов, сколько успеешь") и готовность утонуть там с интервьюером.

Состоит оно из 4 шагов:
1. Сбор требований
2. Высокоуровневый дизайн
3. Низкоуровневый дизайн в некоторых частях
4. Обоснование решения

Что SD, что NALSD, кстати, проверяют умение кандидата ориентироваться в ограниченном пространстве и с минимальным набором требований.

Так, например, у меня был диалог, где я проектировал систему сбора метрик. Как ожидается, я спросил по объемам трафика.

- Ну сам как думаешь?
- Ну у меня порядка 2000 тысяч продюсеров, каждый будет слать метрики раз в минуту. Одна метрика будет висеть.. ну максимум 4 кб. Я могу предположить, что одновременно метрик будет отправляться 10? Или может больше?
- Может больше.
- 100?
- Может и 100, а может и больше.
- Ну тогда два стула: либо я буду начинаю с 10 и делаю throttling, либо считаем ресурсы из расчета 1000 метрик с индивидуального продюсера в секунду. Но это будет неоправданно дорого.

И я, и интервьюер понимаем, что в миру эта задача решается пилотным запуском, нагрузочными тестами и многочисленными замерами. Ну и нужный навык вовремя сказать "Чудес не бывает. Либо так, либо этак." должен быть у любого, кто хоть как-то связан с архитектурой.

В защиту того же CAP. Что CAP, что ACID и BASE надо знать, чтобы доносить до нетехнических коллег пороги возможностей и не обещать им кросс-региональную синхронную репликацию с производительностью асинхронной. Физика, бессердечная ты сука.

Лично мне SD кажется наиболее полезным как минимум потому, что бизнес-системы проектируются куда чаще библиотек и светофоров. Но мой самый любимый вид собеседования - это troubleshooting. Это вообще отдельная песня, если наберется больше ста больших пальцев - расскажу.