Да, вот так сразу :)
Представь, что тебе нужно спроектировать мессенджер. И это, кстати, не такая сложная задача: в базовом варианте тебе достаточно базы данных, backend приложения и frontend (клиента).
Слышу твой вопрос: «В смысле достаточно трех компонентов системы?» Понимаю, скорее всего, ты ожидал, что для мессенджера нужно много различных сервисов, баз данных, а еще kafka запихнуть, чтобы всё летало.
Но проектирование систем — это не «сейчас я соберу все самые модные технологии, поставлю очередь, а еще на модном языке программирования напишу, и все будет тип-топ». Самая крутая система — та, которая решает поставленную задачу.
А в Big Tech, помимо самого решения задачи, важно, чтобы ты знал, как сделать это с наименьшими усилиями. Представь, что ты разработал систему, которая выдержит 1 миллиард посетителей, но это внутренняя система компании, так что в ней будет всего лишь 100 человек.
Да, звучит абсурдно, но именно с таким подходом многие начинают проектировать. Конечно, есть другая крайность — сделать систему, которая от небольшого увеличения нагрузки начинает сыпаться: БД тормозит, а внешние интеграции падают из-за скачков нагрузки. Так тоже плохо, поэтому на курсе мы в том числе поговорим, как подготовить твою систему к нагрузкам.
Но не все сервисы должны выдерживать миллионы запросов. Если «требовать» такого от каждого сервиса, это будет усложнять поддержку системы и тратить лишние ресурсы бизнеса!
Важно научиться не только рисовать во всяких Miro кубики и стрелочки, но и понимать, какую компоненту стоит добавлять в систему, а какую — нет. И не стремиться «собрать всё самое лучшее».
При построении системы нужно идти от потребностей:
- какие у нас входные требования (подробно разберем дальше);
- какие сроки (в рамках сжатых сроков можно сделать шатающийся стул — для MVP, минимальной работоспособной версии, это окей, если надо быстрее проверить гипотезу);
- какое количество пользователей и данных будем обрабатывать.
И дальше эти потребности будут давать нам подсказки, куда идти, а куда нет.
Вообще, в проектировании самое сложное — это как раз смэтчить вводные, часто нетехнические, с техническими возможностями. И понять, какой trade-off (компромисс) нам подойдет, а какой нет.
Лучше сразу смириться — не бывает системы без компромиссов. Где-то быстрее скорость, но при этом меньше надежность. Где-то выше точность, но зато больше занимаемой памяти.