Comments 12
Сайт потыкал - типичный нейрослоп. А статья - запрос на Code Review.
Только вы бы свой Claude и просили вам ревью делать.
Ну и на кой продакту System Design? Или теперь продакт + клод = архитект?
Продакту System Design нужен, чтобы понимать ограничения системы, обсуждать с разработчиками варианты решений и учитывать их последствия для продукта. В моём случае это ещё и был этап собеседования, к которому я готовилась. На роль архитектора я не претендую.
В статье я делюсь учебным инструментом, который сделала для себя и судя по добавлению в закладки, возможно, пригодится кому-либо для собеса (на это и была рассчитана статья). Запроса на code review там нет
Если в вашем комментарии поменять слово "Продакту" на слово "Архитекту" - то изречение станет верным. А если там, куда вы ходили на собеседование, требуется знание вышеперечисленного для продакта - то очевидно это соковыжималка для людей с нулевым пониманием процесса разработки.
По поводу вашего проекта - вам было скучно просто сидеть изучать архитектуру готовых проектов, но было не скучно читать всю ту воду, что выдала вам нейронка? Ну и почему вы решили, что на собесе вам зададут мессенджер? А если бы что-то другое? Соцсеть? файло-помойку? А если бы у вас спросили, почему не рассмотрели Server Side Events + Http для пересылки сообщений?
А вообще, всем, кто готовится к подобным интервью, я бы рекомендовал не изучать отдельно каждое решение, а прочитать пару нормальных книг о System Design. Designing Data-Intensive Applications как одна из них.
Понимать технические ограничения продукта и отвечать за его архитектуру разные задачи. Знания могут пересекаться, от этого продакт не становится архитектором. А вывод о процессах целой компании по одному упоминанию этапа собеседования довольно смелый.
Выбрала мессенджер, поскольку это основной функционал компании, в которую я проходила собес (ну и они сами сказали что будет мессенджер, и стоит немного почитать как он работает =).
Про воду не согласна, нейронка удивительная штука, как вы вопрос сформируете такой ответ и получите. Мне нейронка наоборот помогла все по полочкам в голове разложить и наконец-то разобраться и закрепить материал. Я брала конкретные главы вами же упомянутой книги и просила мне объяснить только на примере мессенджера.
Моему "нишевому проекту" уже почти 30 лет.
Начинался как "фото-альбом", а привёл к альтернативе Вики-энциклопедиям. Своё устройство каталогизации информации и связей с другой информацией.
Сделал только небольшой пример того, как могла бы выглядеть информация в такой системе
На полноценный пример моих знаний и возможностей не хватило
Много слов на эту тему по ссылке
Так ли я понимаю, что, если обобщить, то смысл в том, что UI адаптируется на какую-то подсекцию/ тему, которая всегда остается на экране? Т.е. как если бы Wikipedia была разделена на миллиард под-сайтов?
упс...
Интересно, а что в моих словах могло привести к подобному выводу???
Вообще-то там много разных "смыслов" и основной в том, что на каждую тему/смысл будет не одна статья, как в Вики, а множество разных источников.
И все "предки" каждой темы будут определять "контекст" её понимания, а "потомки" - объяснять тему/смысл
Что касается оформления - то оно может изменяться под необходимые условия - попробуйте понажимать на "кнопочки" правом верхнем углу и подвигать горизонтальный разделитель экрана
Сам формат тренажёра мне нравится: даже как результат подготовки это хороший способ зафиксировать свои решения, проверить их на прочность и передать следующему человеку уже не просто набор мыслей, а основу, которую можно развивать дальше.
Но на собеседовании я бы начал с вопроса: почему здесь вообще Kafka? Какую именно проблему она решает? Какие гарантии доставки нам нужны? Что произойдёт при повторной доставке? Где и как обеспечивается порядок сообщений? Что будет с сообщением, отправленным из метро без сети? А если пользователь одновременно сидит с телефона и ноутбука? Как синхронизируются прочтение и уведомления?
То есть System Design мессенджера я бы начинал не с Kafka и Cassandra, а с того, что именно мы обещаем пользователю. Где хранится история? Что будет, если телефон утонет? Кто способен прочитать переписку? Совместима ли сегодняшняя модель шифрования с теми требованиями, которые могут появиться завтра?
Дальше медиа: превью, MIME type, докачка, транскодирование, хранение, backup. И пользовательские примитивы тоже часть архитектуры: телеграмовские кружочки стали самостоятельным форматом общения. В нашем независимом мессенджере, разумеется, будут пятиугольнички.
И ещё эксплуатация. Добавление нод, замена упавших серверов, обновления и восстановление должны быть рутинными операциями, а не подвигом дежурного администратора.
Вот после того, как определены гарантии, пользовательские свойства и эксплуатационная модель, уже интересно обсуждать Kafka, Cassandra и остальные прямоугольники.
Я себе такие курсы тоже штампую, но руки не доходят почистить их от нейрослопа. ))) Поэтому пока прячу
То есть так ты не понимаешь, ты зубришь. Пц
Интересная штука получилась. Начал с того, что, ничего не зная об архитектуре мессенджеров - начал расставлять кубики, по своему разумению. После этого упражнения текстовые описания писать гораздо веселее.
Но постоянно возникают вопросы. Что конкретно на каждом этапе выбрано, и ПОЧЕМУ? Какие есть альтернативы, какие критерии выбора, и почему выбрано именно предлагаемое решение.
Ну и ещё момент, вопросы к каждому пройденному этапу - в 100% случаев правильный тот, что содержит самый длинный текст. А ведь тоже хотелось поразмышлять, как и над кубиками.
А какое у вас нишевое хобби? Я вот сделала курс по архитектуре мессенджера, пока готовилась к собесу