Как стать автором
Обновить

Комментарии 11

Ну вот вопрос рассчётов он какой-то совсем мутный. Есть у меня какой-то RPS допустим. И дальше надо думать, как его обеспечить. И вот как? Для обеспечения 1000 RPS надо испльзовать какую-то базу данных? Но она же на разных железках может работать, с разным количеством памяти. Почём мне знать, сколько запросов в секунду она мне обеспечит?

Типа взять систему, потом подать на неё нагруку и посмотреть, справляется ли, тут понятно всё. Но заранее как я это пойму?

Поэтому обычно берут при проектировании на собеседовании лучшие цифры, по максимуму. Но! Это очень хороший вопрос и, например, такое могут спросить в конце при обсуждении железа.

Но при HLD и LLD секциях обычно считать можно очень примерно и идеальные случаи

Мы с коллегами читали книгу «Алекс Сюй - System Design. Подготовка к сложному интервью», а затем проводили друг другу mock-интервью. Внезапно выяснилось, что одной книжки недостаточно, и что добрая часть прочитанного забывается. А ещё это навык. Уложиться в план собеседования и тайминг крайне сложно. Mock-собеседования нужны и не одно

Абсолютно так и есть! Более того, я считаю, что этой книжки вообще недостаточно и это можно только как введение использовать.

Книжка мне понравилась, но показалась какой-то однобокой. Там всё про архитектуру высоконагруженных систем. А про архитектуры, сложные в силу каких-то других причин, напр. особенностей предметной области или там требований безопасности, в ней нет.

На мой взгляд книге не хватает глубины - останавливаются в ней всегда на самом важном и интересном месте

Ну и про другие направления верно подмечено.

Сейчас себе взял Чжиюн Тань "System design. Пережить интервью". На первый взгляд, выглядит достаточно плотно по материалу и легко читается. Посмотрим

Если между сервисами начинаются циклические связи (когда сервис 1 ходит в сервис 2, а сервис 2 ходит в сервис 1) - это метрика, чтобы подумать как переделать взаимодействие, например, через ту же очередь и событийную модель

Если между сервисами цикл, то это повод задуматься о том, что это один сервис и имеет место быть неправильное деление по контекстам.

Ну, я об этом примерно и пишу - что это метрика, что что-то не так. Что именно часто зависит от контекста и задачи, поэтому сужать до деления контекстов я не стал, хотя это чаще всего(хоть и не всегда) именно та самая проблема.

Итак, вы делаете стартапчик, который не взлетит с вероятнтстью в 99%, но присобачиваете туда очередь, всякие метрики, load balancer, какието микросервисы, кластеры блин.

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

Блин, вот правда как же это все бесполезно(((...

Что именно? Сам такой собес как этап?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий