Как известно Авторизация в системе относится к функциональным требованиям, так как она описывает конкретное поведение системы - процесс проверки и подтверждения прав пользователя для доступа к системе. Как правило выступает отдельным модулем.
Безопасность - относится к нефункциональным требованиям, так как определяет как система себя ведет с точки зрения защиты.
И требования к авторизации и требования к безопасности, как вы видите, не входят в требования к системе описанной в этой статье.
Но ваши ожидания от статьи я зафиксировал, учту в следующих итерациях или вынесу в отельный материал, спасибо!
Статья не предназначена для подготовки к собеседованию по System Design и уж точно не является полным теоретическим материалом по этой теме. Привожу пример примитивной системы для того, чтобы было понимание последовательности шагов, которой нужно придерживаться при решени задач проектирования. По этапам System Design есть вопрос?
Зачем экстраполировать содержание статьи для новичков или людей которые просто хотят узнать что-то новое, до масштабов руководства по прохождению собеседований и решения реальных задач?
Если бы я хотел написать полное руководство, я бы последнем делом выкладывал ее на Хабр как она есть. Потому что важного материала очень много и он не всегда интуитивно понятен.
С вашей стороны некорректно делать акцент на новичках и не советовать им читать мой материал. Или по по аналогии я предположу, что изучение физики в школе вы сразу начали с Курса теоретической физики Ландау и Лифшица?
Я решил не уходить к микросервисам напрямую, так как цель статьи показать шаги решения задач по System Design.
Если мы говорим, про микросервисы, тогда Link service не должен ходить в БД, в которую пишет Shortener service. Варианты для Link service такие: 1. Либо достает длинные ссылки по коротким из своего Кэша (Redis) 2. Либо из реплики основной БД (куда пишет Shortener service) 3. Либо комбинация
Но тут возникает вопрос Что делать если Кэш сброшен или в реплике неактуальные данные?) Мы снова приходим к распределенному монолиту, так как приходится вызывать основную БД
В таком случае для Кэша 1. нам на помощь может прийти Kafka для асинхронного восстановления кэша: Кэш-воркер постоянно подписан на Kafka и восстанавливает Redis при сбоях (из истории Kafka). Так Kafka используется для асинхронного взаимодействия между Link service и Shortener service. 2. Резервный кэш - всегда есть еще один Кэш (Redis), готовый прийти на помощь в случае сбоя.
Если только реплика (без кэша) и она неактуальна, то мы тут как не крути либо возвращаем ошибку и ждем пока все синхронизируется, либо идем опять основную БД, тем самым порождая распределенный монолит
Что касается реплики и кеша вместе - то тут нужно чтобы TTL в Redis, покрывал синхронизацию мастера и реплики (То есть удаляя запись из Кэша, мы должны быть уверены что она появилась в реплике)
Либо Вообще сделать отдельный сервис на преобразование длинного в короткий ( сохранение в свое БД) и отдельный сервис для получения длинного из короткого (получаем из Кэша) - например как Bit.ly, но тогда все равно есть Кафка, Кэш-воркеры и периодические запросы основной БД.
Как вы видите такие рассуждения выбиваются из общей тематики статьи, поэтому и не подсвечиваются.
Сегодня зоопарк технологий и завышенные требования к кандидатам, автоматизация процессов зачастую заставляют забывать о том что мы больше чем просто винтики, которые должны быть встроены в очередную организацию. И страх того, что ты как "деталь", можешь не подойти в существующий механизм, становится сильнее чем моральный настрой и условия труда.
Важно помнить, что кандидаты тоже люди со своими желаниями, амбициями и чувствами и лучшее что мы можем сделать при подготовки к собеседованию, прислушиваться к ним.
Вы правы, задачи на собеседовании и не только по System Design в большинстве случаев мало схожи с реальностью. Например в Т Банке собес по System Design для системных аналитиков это промежуточный этап отбора, на который выделяется 1.5 часа плотной работы с интервьюером. Там вас спросят обо всем. Я когда приходишь на проект, там вялотекущее развитие архитектуры в течении нескольких кварталов, причем как правило за это вообще отвечает Solution architect и приходится просто писать ФТ и НТ. Также и во всем финтехе.
Но если подумать, когда на 1 позицию метит N человек, вам приходится выбирать и для того, чтобы разметить поле выбора приходится вводить всякие новые этапы собеседований и безумные задания. System Design олицетворяет фундамент IT - как создается то или иное приложение, система и тд. Знание основ, базовых технологий и принципов снимает риск, что кандидат после принятия оферта будет балластом.
Естественно тут мы говорим только про hard skills, и не упоминаем что неопытный кандидат может на своих Soft Skills и упорстве оперативно во всем разобраться и стать ключевым звеном в команде (Это слишком непрозрачно на этапе собеседования). Но Харды проверяются легче софтов, поэтому на собеседовании есть этап с System Design.
Бизнес требования - как общие требования к продукту (именно что должно быть сделано? - функциональные требования) и правда дают страт проектированию, но зачастую делается акцент на общий функционал без углубления в ограничения (Сроки, Бюджет, рынок и тд.).
На мой взгляд вы не очень любезны, однако надеюсь, что каждый открываемый вами материал будет соответствовать вашим ожиданиям.
Как известно Авторизация в системе относится к функциональным требованиям, так как она описывает конкретное поведение системы - процесс проверки и подтверждения прав пользователя для доступа к системе. Как правило выступает отдельным модулем.
Безопасность - относится к нефункциональным требованиям, так как определяет как система себя ведет с точки зрения защиты.
И требования к авторизации и требования к безопасности, как вы видите, не входят в требования к системе описанной в этой статье.
Но ваши ожидания от статьи я зафиксировал, учту в следующих итерациях или вынесу в отельный материал, спасибо!
Добрый день.
Статья не предназначена для подготовки к собеседованию по System Design и уж точно не является полным теоретическим материалом по этой теме. Привожу пример примитивной системы для того, чтобы было понимание последовательности шагов, которой нужно придерживаться при решени задач проектирования. По этапам System Design есть вопрос?
Зачем экстраполировать содержание статьи для новичков или людей которые просто хотят узнать что-то новое, до масштабов руководства по прохождению собеседований и решения реальных задач?
Если бы я хотел написать полное руководство, я бы последнем делом выкладывал ее на Хабр как она есть. Потому что важного материала очень много и он не всегда интуитивно понятен.
С вашей стороны некорректно делать акцент на новичках и не советовать им читать мой материал. Или по по аналогии я предположу, что изучение физики в школе вы сразу начали с Курса теоретической физики Ландау и Лифшица?
Хороший вопрос)
Я решил не уходить к микросервисам напрямую, так как цель статьи показать шаги решения задач по System Design.
Если мы говорим, про микросервисы, тогда Link service не должен ходить в БД, в которую пишет Shortener service. Варианты для Link service такие:
1. Либо достает длинные ссылки по коротким из своего Кэша (Redis)
2. Либо из реплики основной БД (куда пишет Shortener service)
3. Либо комбинация
Но тут возникает вопрос
Что делать если Кэш сброшен или в реплике неактуальные данные?) Мы снова приходим к распределенному монолиту, так как приходится вызывать основную БД
В таком случае для Кэша
1. нам на помощь может прийти Kafka для асинхронного восстановления кэша: Кэш-воркер постоянно подписан на Kafka и восстанавливает Redis при сбоях (из истории Kafka). Так Kafka используется для асинхронного взаимодействия между Link service и Shortener service.
2. Резервный кэш - всегда есть еще один Кэш (Redis), готовый прийти на помощь в случае сбоя.
Если только реплика (без кэша) и она неактуальна, то мы тут как не крути либо возвращаем ошибку и ждем пока все синхронизируется, либо идем опять основную БД, тем самым порождая распределенный монолит
Что касается реплики и кеша вместе - то тут нужно чтобы TTL в Redis, покрывал синхронизацию мастера и реплики (То есть удаляя запись из Кэша, мы должны быть уверены что она появилась в реплике)
Либо Вообще сделать отдельный сервис на преобразование длинного в короткий ( сохранение в свое БД) и отдельный сервис для получения длинного из короткого (получаем из Кэша) - например как Bit.ly , но тогда все равно есть Кафка, Кэш-воркеры и периодические запросы основной БД.
Как вы видите такие рассуждения выбиваются из общей тематики статьи, поэтому и не подсвечиваются.
Спасибо за комментарий.
Избегаем игнорирования региональных цен)
Спасибо за комментарий.
Даже есть связь с названием статьи.
Интересно)
Как вы считаете в чем разница в эмоциях от нахождения в очереди за Ламборджини и при прохождении собеседовании в хорошую компанию, по мерках рынка?
Как страх не получения той самой бесплатной ламбы, отличается от страха не попасть в "компанию мечты"?
Спасибо, за комментарий.
Верно. Новое, хорошо забытое старое.
Сегодня зоопарк технологий и завышенные требования к кандидатам, автоматизация процессов зачастую заставляют забывать о том что мы больше чем просто винтики, которые должны быть встроены в очередную организацию. И страх того, что ты как "деталь", можешь не подойти в существующий механизм, становится сильнее чем моральный настрой и условия труда.
Важно помнить, что кандидаты тоже люди со своими желаниями, амбициями и чувствами и лучшее что мы можем сделать при подготовки к собеседованию, прислушиваться к ним.
Добрый день. Спасибо за комментарий.
Вы правы, задачи на собеседовании и не только по System Design в большинстве случаев мало схожи с реальностью. Например в Т Банке собес по System Design для системных аналитиков это промежуточный этап отбора, на который выделяется 1.5 часа плотной работы с интервьюером. Там вас спросят обо всем. Я когда приходишь на проект, там вялотекущее развитие архитектуры в течении нескольких кварталов, причем как правило за это вообще отвечает Solution architect и приходится просто писать ФТ и НТ. Также и во всем финтехе.
Но если подумать, когда на 1 позицию метит N человек, вам приходится выбирать и для того, чтобы разметить поле выбора приходится вводить всякие новые этапы собеседований и безумные задания. System Design олицетворяет фундамент IT - как создается то или иное приложение, система и тд. Знание основ, базовых технологий и принципов снимает риск, что кандидат после принятия оферта будет балластом.
Естественно тут мы говорим только про hard skills, и не упоминаем что неопытный кандидат может на своих Soft Skills и упорстве оперативно во всем разобраться и стать ключевым звеном в команде (Это слишком непрозрачно на этапе собеседования). Но Харды проверяются легче софтов, поэтому на собеседовании есть этап с System Design.
Добрый день.
Бизнес требования - как общие требования к продукту (именно что должно быть сделано? - функциональные требования) и правда дают страт проектированию, но зачастую делается акцент на общий функционал без углубления в ограничения (Сроки, Бюджет, рынок и тд.).