System Design: backend

Обещали разобрать бэк - делаем. Задачка с собеса в Сбере: нужно передавать файлы большого размера. Через мессенджер не выйдет, упрёмся в лимиты, значит либо торрент, либо поднимать свой сервер, либо что-то ещё. Как спроектируешь?

Стоит начать не идти в лоб решать, а задать парочку вопросов, например я начал бы с такого: отправитель и получатель должны быть онлайн одновременно? Ну и попутно выясняем размер файлов, один получатель или тысячи качают одно и то же, сколько файл живёт и не корпоративная ли это сеть - потому что в корпоративной сети половина P2P просто не взлетит.

Дальше развилка, ради которой задачу и дают. Можно пойти в P2P, когда файл льётся напрямую между участниками, а мы храним только метаданные. Мы не платим за хранение и за исходящий трафик, и чем популярнее файл, тем быстрее раздача, потому что получатели сами становятся источниками. Но обе стороны обязаны быть онлайн одновременно, придётся возиться с NAT и фаерволами, а фолбэк на релей - это уже снова наш сервер и наш трафик. Можно пойти централизованно: отправитель залил, получатель забрал когда захотел, никто никого не ждёт, но мы платим за хранение и, главное, за исходящий трафик, который тут и будет основной статьёй расходов. А в проде почти всегда получается гибрид, где метаданные, авторизация и сигналинг идут через наш сервер, а данные - напрямую между клиентами, где это возможно. Вот эту мысль и надо озвучить: выбор определяется требованиями.

Что бы ты ни выбрал, файл целиком одним куском не гоняем никогда, режем на чанки. Отсюда сразу берётся возобновляемость - оборвалась сеть на N гб, дослали недостающие куски, а не начали всё сначала. Берётся параллельность, потому что несколько чанков льются одновременно и утилизируют канал. Берётся дельта-передача: правка внутри десятигигабайтного видео превращается из десяти гигабайт трафика в пару десятков мегабайт. Считаем хеш каждого чанка — и получаем дедупликацию, когда один и тот же файл, залитый сотней людей, лежит в единственном экземпляре, и заодно контроль целостности, когда битый кусок видно сразу и перекачивается только он.

По хранению главное не смешивать вещи в кучу. В базе лежит запись о файле и ссылки на чанки, сами чанки - в объектном хранилище. И клиент заливает и качает напрямую туда по подписанной ссылке с ограниченным сроком жизни, минуя наши приложения, потому что если ты пропустишь пятьдесят гигабайт через свой бэкенд, ты его положишь. Наш сервис только выдаёт ссылку и пишет метаданные, а раздача идёт через CDN с поддержкой range-запросов, чтобы качалка умела докачивать.

И главное, что стоит понимать про эту задачу. Интервьюеру в общем-то всё равно, что ты в итоге выбрал - торрент, свой сервер или гибрид. Ему важно, назовёшь ли ты условие, при котором выбрал бы другое. Пока ты рассуждаешь "раздача на тысячи получателей — значит P2P окупается, а тут передача один на один и получатель офлайн - значит хранилище", ты проходишь секцию. Как только не рассматриваешь другое решение при других вводных, а стоишь на одном и том же, то это сильно режет твои шансы на успешное прохождение собеса.

Подписывайтесь на канал и вступайте в чатик, товарищи, так вы не пропустите новый контент!

Подписаться: @codeof_art