Comments 35
Сокращатель ссылок - это хорошо.
Плохо, что такие ссылки, да на незнакомый ресурс, могут восприеиматься как что-нибудь нехорошее.
Если честно, я так и не понял, почему после добавления балансировщика, клиент вдруг стал ходить к Shortener Service напрямую)
Overkill на этапе выбора БД. Поскольку сервис заявлен, как крайне примитивный, а в метаданных очень сложно придумать отношения, то реляционная база данных здесь не нужна, и гораздо лучше подошла бы NoSQL база (например, GDB, MDB, dBase), которые работают вообще, как пулемет, имеют весьма лаконичный и строгий API и дадут огромный выигрыш уже тем, что этапы разбора запроса и планирование его выполнения отсутствуют как таковые.
Вспомним, хотя бы, бенчмарки openldap (штатный сторадж у нее GDB, если не изменяет память), которая (даже с парсером LDAP запроса) показывала сотни тысяч RPS в начале 2000-х, естественно, на железе того времени.
"Сервис опалы" звучит интригующе. "Сервис анафемы" еще предлагаю запилить.
Зачем тут распределённый монолит с общей базой под видом двух сервисов? Видно же, что это только усложняет логику и не даёт вообще никаких профитов.
Хороший вопрос)
Я решил не уходить к микросервисам напрямую, так как цель статьи показать шаги решения задач по 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 , но тогда все равно есть Кафка, Кэш-воркеры и периодические запросы основной БД.
Как вы видите такие рассуждения выбиваются из общей тематики статьи, поэтому и не подсвечиваются.
А у автора есть реальный опыт проектирования и защиты сайзинга для сколь-нибудь сложных систем? А то тут что не пункт - то ошибка проектирования (
Осуждаешь? Предлагай! Распиши ошибки и свой вариант решения!
Пишем простейший сервис, использующий децентрализованную конвергентную базу данных. Поднимаем его на нужном числе узлов в разных дата-центрах. Балансируем нагрузку через dns. Всё. Никаких Кафок, Редисов, Постгресов, балансировщиков, микросервисов и прочих звездолётов, скрепленных изолентой. При этом получаем синхронизацию узлов в реальном времени, устойчивость к разделению сети, неограниченное горизонтальное масштабирование, автоматическое восстановление при сбоях, локальную авторизацию, шаринг прав, и отработку каждого запроса за миллисекунды.
А цена вопроса? Есть ли такие в мире опенсорс?
Конечно: crus.hyoo.ru
"Сохранность данных не гарантируется" отличная база данных.
На то она и бета версия. Можете задонатить, чтобы ускорить релиз.
Так сохранность не гарантируется потому что скоро выйдет новое апи с другим форматом хранения данных, и потому что для хранения используются сервера добровольцев(это чтобы можно было легко протестировать свой проект)
Если да, то Link service , сразу возвращает это корочку ссылку. Если нет, то он обращается к Shortener service, для генерации короткой ссылки.
Привет отслеживанию переходов и тестированию эффективности информационных площадок.
Для новичков: я бы не стал руководствоваться этой статьей при подготовке к System Design. Найдите книжку топ 100 типовых задач на систем дизайн интервью и посмотрите 5 роликов на Ютубе на английском и 5 на русском. Чтобы понимать, в каком стиле может быть коммуникация с инеивртювером. И делать это за недели 2-3 до собесов, чтобы было свежо в голове. Это спринт, а не марафон.
Секрет System Design секции интервью в том, попадется ли вам знакомая задачка и какое будет настроение у интервьювера. Но даже если вам попадется именно задача на сокращатель ссылок, то с таким решением как в статье вас развернет даже интервьювер, у которого вчера жена родила.
Секрет System Design в том, что даже одну и ту же систему мы можем построить по разному.
Соответственно, типичный интервьювер решение задачи интерпретирует как хочет, особенно оценка будет не в вашу пользу, если вы решаете задачу не так, как в методичке, или не так, как решил бы ее сам интервьювер. Гейм Овер.
Нет «идеального» дизайна — есть оптимальный для конкретных требований и усоливий.
Даже для конкретных требований и условий бывают очень разные градации оптимальности. Все зависит от степени детализации требований. Чем дольше собираются требования, тем позже начало разработки, но тем выше точность в выборе решения. В современном Agile мире дизайн не бывает оптимальным никогда, так как требования собираются прямо в процессе разработки. Помимо всего прочего, команду болтает со стороны в сторону: что-то не учел PO, новая аналитика от продакт менеджера показывает, что пользователю нужно B, а изначально разрабатывалось под А. Поэтому дизайн получается просто минимально рабочим. Я думаю не нужно объяснять разницу между "оптимально" и "минимально жизнеспособно". И чем дольше разрабатывается продукт в таком режим, тем менее жизнеспособным он становится - постоянные сбои в одном месте из-за того, что "ветер подул" в другом. И тут такие исходы:
Продукт умирает в зародыше по не техническим причинам (1-12 месяцев).
Продукт умирает от того, что тот способ, которым строили минимально жизнеспособно решение не выдержал конкуренции и в конечном итоге начал отставать от конкурентов по скорости внедрения фич (через 1-3 года). Причем у конкурентов тоже может быть криво косо, но инвестор залил больше денег и теперь не 9 женщин рожает ребенка за месяц, а 19. А может быть и так, что денег залили вам, но у конкурента его 9 женщин рожает быстрее, чем ваши 19. В общем это отчасти лотерея.
Продукт растет, но выживает на грани, скорость внедрения фич критически минимальная, стоимость обслуживания критически максимальная (3-6 лет); но база клиентов покрыта и рефакторинг начался более менее вовремя. Но проблема в том, что его делают те люди, которые делали "чтобы заработало" и делать "оптимально" они не знают как, а если и знают, то уже забыли; в результате рефакторинга получается чуть менее уродливое нечто и так до следующего рефакторинга через 2-3 года.
Продукт выживает на грани, но без рефакторинга. Новые фичи перестают добавляться. Продукт превращается в Легаси и уходит на саппорт (6+ лет до бесконечности).
Продукт изначально строится как клон какого-то другого софта. Тут можно попробовать построить что-то оптимальное, но где вы найдёте людей, которые обладают нужными знаниями и опытом... В итоге получается чуть лучше и чуть дешевле, чем у конкурента и может быть даже получится переманить часть аудитории. Или "импортозаместить". А может быть и нет.
Реальная работа это: придти на новый проект и разобраться, как он устроен. Найти способ добавить новую фичу и не сломать существующие. Перед этим провести валидацию требований, а достаточно ли информации, чтобы сделать хоть что-то. Протянуть эту фичу по всей системе. И тд.
Поэтому системный архитектор сейчас это просто самый опытный человек в компании с точки зрения знания продукта и его технической реализации; и его самая главная задача, это помогать добавлять новые функции на кросс-командном уровне, чтобы сохранить "минимальную жизнеспособность". Откуда ему знать, как делать оптимальные системы, если он сам с ними никогда не работал и у него такой задачи не стоит.
А так, систем дизайн интервью проверяет только одну вещь - как вы готовились к систем дизайн интервью и вашу удачу. Вот и думайте.
Добрый день.
Статья не предназначена для подготовки к собеседованию по System Design и уж точно не является полным теоретическим материалом по этой теме. Привожу пример примитивной системы для того, чтобы было понимание последовательности шагов, которой нужно придерживаться при решени задач проектирования. По этапам System Design есть вопрос?
Зачем экстраполировать содержание статьи для новичков или людей которые просто хотят узнать что-то новое, до масштабов руководства по прохождению собеседований и решения реальных задач?
Если бы я хотел написать полное руководство, я бы последнем делом выкладывал ее на Хабр как она есть. Потому что важного материала очень много и он не всегда интуитивно понятен.
С вашей стороны некорректно делать акцент на новичках и не советовать им читать мой материал. Или по по аналогии я предположу, что изучение физики в школе вы сразу начали с Курса теоретической физики Ландау и Лифшица?
По этапам System Design есть вопрос?
Разумеется. Вопрос безопасности не рассмотрен вообще. А авторизация улетела в "дополнительные опциональные фичи".
Как известно Авторизация в системе относится к функциональным требованиям, так как она описывает конкретное поведение системы - процесс проверки и подтверждения прав пользователя для доступа к системе. Как правило выступает отдельным модулем.
Безопасность - относится к нефункциональным требованиям, так как определяет как система себя ведет с точки зрения защиты.
И требования к авторизации и требования к безопасности, как вы видите, не входят в требования к системе описанной в этой статье.
Но ваши ожидания от статьи я зафиксировал, учту в следующих итерациях или вынесу в отельный материал, спасибо!
Ага, обновите промпт, может хоть с восьмой попытки у вас получится статья по System Design без вопиющих косяков.
А RPS, CCU, R, A точно важнее авторизации и аутентификации? А как же панель управления, аналитика и другие элементы системы, которые имеют ключевую бизнес ценность? Что да двойные стандарты.
Наклепали (не Вы конкретно) какой-то горе-фреймворк для расчета сферического коня в вакууме, и теперь пытаетесь подогнать реальность под него (Вы в частности). Типа "мы не придумали как это считать и чтобы классно на интервью выглядело, поэтому давайте не считать".
А можно хотя бы один жизнеспособный пример авторизации в отношении анонимных пользователей?
На мой взгляд такой материал не несёт никакой ценности для тех, кто всё-таки решил разобраться в системном дизайне.
Джунам и миддлам не до этого, им бы просто основы языка и среды разработки понять (включая базовые принципы развертки, CI/CD, базы данных, юнит тестирование и ТД).
А синьеров с ролью тех лида Ваш пример собьёт с толку. Как делать рассчет уже написана масса статей, Вы сами приводите ссылки. А дизайн у Вас получился как минимум спорный, и чего-то новое подчерпнуть не сможет даже техлид в небольшом стартапе (5-6 лет опыта), а уж техлид в бигтехе (10+ лет опыта) тем более.
Остаются всякие недосиеньеры, которые каждый год ходят по собесам в надежде заткнуть собой какую-нибудь дырку за побольше денег. Но для них стратегия другая. Думать и понимать не надо, надо заучить, "задрочить", и пока не забыл идти на интервью. Потому что на самой работе все будет совсем не так.
Тогда для кого статья?
Я в комментарии старался подсветить читателю стати, что не надо думать, что читатель какой-то не такой, если его опыт совсем другой, если он не согласен с Вашим решением. Если у него есть свое решение, а его предложения заворачивают "более опытные" на работе или на интервью. Возможно его решение даже технически лучше "старшего" или "экзаменатора", он подошёл более творчески и креативно, но язык у него подвешен не как у старшего или синдром самозванца. И это надо проламывать, в себе настаивать, искать способы донести бизнесу и команде свой вариант технического решения, но и при этом слушать обратную связь и учиться ее фильтровать. Если критика по делу, а не вкусовщина - принять, поправить решение, выучить что-то новое, заполнить пробелы. Если критика в роде "я говорю твое решение говно, значит говно" - тоже сделать выводы, но уже не о себе.
Откуда взялись 300 долларов за гигабитное соединение? На всех хостингах это обойдётся максимум 1к как допуслуга а чаще это встроено в тариф(хотя 3 моих любтивх хостинга до машины за 3к дают только 200-250мбит)
У меня есть замечание к статье - оно в разделе "Выбор базы данных"
На настоящем System Design собесе вас как раз попросят объяснить выбор PostgreSQL и ответ типа:
> Будем использовать реляционную СУБД PostgreSQL. Потому что наша таблица имеет строгую структуру и нам важна быстрота
Вас не спасет. Как раз это тот вопрос и то место, которое точно "будут качать", а по формулировке почти любая БД вам подойдет (плюс непонятно при чем тут строгая структура).
Второй важный момент, который упущен, это то, как вы будете генерировать уникальные короткие ссылки - ответ на этот вопрос как раз влияет на архитектуру и нагрузку очень серьезно.
Вот эти два момента - они основные и вам надо их доработать. А статья написана аккуратно, читать приятно было.
Шаг за шагом проектируем сокращатель ссылок